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Preface 


This  thesis  was  completed  in  response  to  a request  to  develop  a 
model  of  a back-end  data  base  processor  for  the  Air  Force  Military  Per- 
sonnel Center  (AFMPC) . The  current  computer  system  at  the  AFMPC  is  heavily 
utilized,  and  this  has  caused  an  increase  in  the  time  between  data  base  file 
updates.  A back-end  data  base  processor  system  conf iguration  is  one  possible 
solution  to  these  problems. 

The  size  and  complexity  of  the  Air  Force  personnel  system  and  the  AFMPC 
data  management  system  dictated  that  the  complete  project  be  divided  into 
several  phases.  This  thesis  is  the  first  step,  or  phase,  and  it  provides 
the  foundation,  background,  and  direction  for  the  future  studies  that  r-.ro 
required  to  satisfy  the  initial  request.  Alternate  solutions  to  the  system 
problems  should  be  investigated,  and  this  thesis  may  be  used  as  a foundation 
for  those  investigations  as  well. 

I wish  to  thank  my  thesis  advisor,  Captain  Peter  H.  Miller,  for  the 
encouragement,  advice,  and  confidence  he  expressed,  especially  when  progress 
was  slow  and  difficult.  The  editoral  comments  of  my  thesis  readers,  Major 
Kenneth  Melendez  and  Captain  James  B.  Peterson,  axe  also  appreciated. 

Special  thanks  must  go  to  Captain  Leslie  J.  Waguespac.k  for  his  outstanding 
support  throughout  the  investigation  and  his  editoral  comments  during  the 
preparation  of  this  thesis.  Thinks  are  also  due  to  Miss  Cindy  Held  for 
typing  this  manuscript.  Finally,  I deeply  appreciate  the  support  and 
encouragement  of  my  wife,  Dianne,  and  my  children,  Carla  and  Brian;  who 
tolerated  my  various  moods  and  sacrificed  tremendously  so  that  I could 
complete  this  work. 

Lester  F-.  Nagel 
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Abstract 


Members  of  the  Air  Force  Military  Personnel  Center  (AFMPC)  want  to 
investigate  the  feasibility  of  utilizing  a back-end  data  base  processor 
system  configuration  for  the  AFMPC  personnel  data  management  system.  This 
thesis  surveys  the  current  system,  the  personnel  management  organization 
(AFMPC),  the  back-end  data  base  processor  concept,  and  the  general  require- 
ments of  the  system.  The  basic  problems  of  the  current  system  are  that  it 
is  (1)  heavily  utilized,  and  (2)  the  data  base  files  cannot  be  updated  on 
a timely  basis  because  of  the  heavy  workload.  The  back-end  data  base 
processor  concept  is  relatively  new  and  may  provide  a solution  to  these 
problems.  Consequently,  a discussion  of  the  back-end  concept,  its  advan- 
tages, and  disadvantages  is  presented.  In  addition,  the  general  require- 
ments of  the  system  are  discussed  and  are  divided  into  two  categories; 

(1)  functional  requirements,  and  (2)  system  requirements. 

The  cb  scussions  of  the  current  system,  the  personnel  management 
organizatioii , the  back-end  concept,  and  the  general  requirements  provide  a 
foundation  for  future  studies  th3t  will  be  required  to  (1)  solve  the  system 
problems,  and  (2)  model  a back-end  data  base  processor  system  configuration 
for  the  AFMPC.  In  addition  to  the  background  and  foundation  for  future 
studies,  a focus  and  direction  for  those  studies  is  also  presented.  The 
focus  and  direction  for  future  studies  is  provided  through  (1)  an  analysis 
of  the  current  system,  (2)  a plan-of-attack  that  can  be  used  to  solve  the 
data  management  problems  of  the  system,  and  (3)  a brief  look  at  the 
application  of  a back-end  data  base  processor  at  the  AFMPC. 
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SYSTEM  SURVEY  WITH  A VIEW  TOWARD  UTILIZING  A 
BACK-END  DATA  3ASE  PROCESSOR 

I Introduce  ion 

This  thesis  was  requested  by  members  of  the  Directorate  of  Personnel 
Data  Systems  (I)PMD)  in  the  Air  Force  Military  Personnel  Center  fAFMPC) 
located  at  Randolph  AFB,  Texas.  They  requested  that  a back-end  data  base 
processor  configuration  for  the  Air  Force  personnel  data  management 
system  be  investigated,  modeled,  and  evaluated.  This  thesis  provides  the 
background  and  foundation  for  future  studies  that  are  required  to  fulfill 
that  request. 

General 

The  Air  Force  Military  Personnel  Center  (AFMPC)  at  Randolph  AFB, 
Texas,  is  responsible  for  the  management  of  the  personnel  resources  of 
the  United  States  Air  Force  (USAF) . A USAF  regulation,  APR  8-12  dated 
14  February  1975,  identifies  the  USAF  Personnel  Plan  (USAFPP)  as  the 
"fundamental  and  pervasive  authority  on  overall  personnel  policy,  pre- 
scribing the  Air  Force  approach  to  'total  force'  management."  The 
AFMPC  automated  data  processing  (ADP)  system(s)  must  support  the  USAF 
personnel  management  objectives  outlined  in  the  USAFPP.  These  objectives 
fall  into  the  five  broad,  functional  areas  of  personnel:  (1)  procurement, 
(2)  education  and  training,  (5)  utilization,  (4)  sustentation,  and  (5) 
separation.  Currently,  AFMPC  maintains  records  on  more  than  1.2  million 
people  in  the  following  categories:  (1)  active  duty  military  (USAP), 

(2)  Air  Force  Reserve,  (5)  Air  National  Guard,  and  (4)  civilian  employees 
of  the  Air  Force.  In  addition,  records  are  maintained  on  individuals 
who  have  served  in  the  Air  Force,  but  are  currently  retired  or  separated. 
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from  active  duty.  Over  35  percent  of  *’he  Air  Force  budget  is  expended 
on  people  related  costs  to  keep  the  force  in  a high  state  of  readiness 
(Ref  1:1).  Therefore,  it  is  essential  that  the  Air  Force  manage  its 
people  as  effectively  and  as  efficiently  as  possible. 

Background 

The  personnel  management  system  has  evolved  from  a manual  record 
keeping  function  at  squadron  or  group  level  to  the  highly  automated 
system  of  today.  The  evolution  began  when  the  squadron  and  group 
functions  were  consolidated  into  Consolidated  Base  Personnel  Offices 
(CBPOs)  at  base  level.  Automated  record  keeping  systems  were  developed 
at  base  level  to  manage  the  large  volume  of  data  and  reduce  the  number 
of  personnel  support  technicians.  Initially,  there  was  little  if  any 
standardization  in  the  use  of  automated  personnel  data  management  systems. 
Then  several  of  the  Major  Commands  (MAJCQMs)  began  to  standardize  the 
automated  personnel  data  systems  within  their  respective  commands.  These 
systems  improved  the  effectiveness  of  intra-command  personnel  data 
management,  but  inter-command  personnel  data  management  activities 
remained  poor  due  to  the  lack  of  standardization  between  commands.  In 
1962,  the  goals  and  concepts  of  a standardized  USAF  system  were  published 
in  the  Long  Range  Pl_an  for  the  Personnel  Management  System.  After  this 
plan  was  implemented,  personnel  support  technicians  could  transfer  inter- 
command with  very  little  training,  many  MAJCOM  unique  directives  were 
eliminated,  standardized  reports  could  be  transmitted  between  the  MA1CC  is 
and  Headquarters  USAF,  and  data  collected  at  one  base  could  be  utilized 
at  any  other  base. 

Major  advances  in  computer  and  communications  technology  are 
gradually  leading  to  the  development  of  a centralized  personnel  data  base 
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located  in  the  AFMPC  at  Randolph  AFB,  Texas.  In  April  1974  , the 
Advanced  Personnel  Data  System  was  implemented.  Mien  this  system  is 
fully  exploited,  the  AFMPC  will  handle  the  data  management  function  for 
the  MAJCOMs.  The  MXJCOMs  will  interact  with  this  centralized  system 
through  the  use  of  leased  telephone  communication  circuits  and  AUTODIN  II 
communication  circuits  as  soon  as  they  are  available.  Some  consideration 
is  being  given  to  incorporating  the  base  level  CBPO  data  management  func- 
tions with  the  data  management  functions  at  the  AFMPC  in  the  Future. 
Initial  deployment  and  testing  of  base  level  equipment  configurations 
is  scheduled  to  begin  within  the  next  year. 

Presently,  the  data  management  functions  at  the  AFMPC  are  accom- 
plished on  two  Burroughs  B6700  computer  systems (Ref  2).  These  systems 
operated  independently  and  were  not  linked  in  any  way  until  recently. 

A software  package  was  written  by  the  AFMPC  in  late  1977  that  facilitates 
access  by  both  systems  to  a common  disk  resource.  The  "A"  system  is  the 
largest,  and  it  handles  the  majority  of  the  personnel  data  management 
transactions.  The  "B"  system  is  utilized  to  support  the  Procurement 
Management  Information  System  (PROMTS).  PROMIS  provides  the  USAF 
recruiters  throughout  the  world  with  on-line  access  to  a central  quota 
data  bank.  This  system  is  used  to  match  an  applicant's  qualifications  and 
interests  with  potential  jobs  that  are  available  in  the  Air  Force. 

Probl em 

The  current  computer  systems  consistently  have  a heavy  workload  and 
are  being  utilized  at  near  peak  capacity  at  ail  times.  This  has  led  to 
some  rigid  controls  and  restrictions  in  data  processing  on  the  AFMPC 
computer  systems.  The  full  impact  of  changes  in  personnel  resources  may 
not  be  reflected  for  several  days  or  possibly  two  or  three  weeks,  because 


because  personnel  data  base  files  are  only  updated  periodically.  This 
situation  does  not  allow  the  AFMPC  to  have  a current  data  base  on  a 
timely,  day-to-day  basis  nor  does  the  heavy  workload  allow  optimum 
response/turnaround  time  for  normal  personnel  data  processing  activities. 
These  two  factors  adversely  affect  the  quality,  accuracy,  and/or  timeliness 
of  data  and  reports,  which  in  turn  adversely  affects  personnel  management 
actions . 

Presently,  the  AFMPC  data  base  structure  consists  of  several  files. 

The  number  of  files  identified  as  data  base  files  will  vary  depending  upon 
the  eyes  of  the  beholder.  At  a minimum,  the  data  base  includes  the  eight 
Master  Personnel  Files  (MPFs),  and  it  may  include  13  or  more  subsystems 
which  contain  selected  portions  of  one  or  more  of  the  MPFs.  The  subsystem 
files  can  be  updated  independently  or  concurrently  with  the  appropriate 
MPFs.  These  files  are  only  updated  at  selected  intervals.  Some  files 
are  updated  as  often  as  three  times  per  week  while  others  may  only  be 
updated  once  per  month  (Table  I).  Table  I contains  some  file  statistics 
and  update  transaction  statistics  which  were  extracted  from  an  APDS 
orientation  briefing  presented  to  the  author  at  the  AFMPC. 

The  AFMPC  data  base  system  is  large  and  very  complex.  This  system 
must  produce  a data  base  that  is  accurate  and  up-to-date  if  personnel 
resources  are  going  to  be  managed  efficiently  and  effectively.  The 
accuracy  of  the  data  base  files  is  dependent  upon  the  frequency  of  the 
updates  and  the  amount  of  interaction  between  the  different  files.  A 
transaction  on  one  can  affect  either  directly  or  indirectly  many  other 
files.  For  example,  an  enlisted  airman  who  receives  a commission  through 
Officer  Training  School  (OTS)  must  be  removed  from  the  "active  airman" 
file  and  placed  upon  the  "active  officer"  file.  When  he  was  assigned 
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Table  I.  AFMPC  Data  Base  File  Statistics  (Ref  3) 
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to  OTS,  he  was  replaced  by  another  individual  who  may  have  been  recruited 
and/or  required  some  formal  training.  This  sequence  of  actions  would 
affect  at  least  two  MPFs  and  three  subsystem  files. 

During  the  author's  visits  to  the  AFMPC,  the  complexity  of  the 
interactions  between  files  was  discussed  briefly.  A summary  of  the 
comments  on  the  interaction  between  files  is  that,  "No  single  person 
understands  all  of  the  interactions  between  the  files,  nor  does  any  single 
person  Know  exactly  what  data  is  contained  in  the  different  files."  No  one 
seemed  to  know  where  this  information  could  be  located  without  talking  to 
the  different  programmers  who  work  with  the  files.  There  are  literally 
thousands  of  pages  of  documentation  on  detailed  system  characteristics, 
but  there  is  little,  if  any,  documentation  that  explains  the  characteristic 
of  the  files  or  the  interaction  between  files. 

Since  the  data  base  updates  take  so  much  time,  they  are  completed 
at  intervals  that  are  determined  by  the  file's  relative  importance  in 
resource  management.  The  personnel  support  staff  must  have  accurate, 
timely  information  to  manage  and  monitor  actions  that  affect  the  force; 
i.e.  promotions,  assignments,  separations,  training,  and  many  others. 

The  volume  of  data  that  is  maintained  in  each  data  base  file  and  the 
dynamic  character  of  the  data  make  it  essential  that  new  and  more 
effective  data  management  systems  be  developed  and  evaluated  for  possible 
use. 

Several  individuals  in  the  Directorate  of  Personnel  Data  Management 
Division  at  the  AFMPC  have  on  intuitive  feeling  that  a back-end  data 
processor  will  allow  timely  updates  to  the  data  base  files  and  improve  the 
overall  quality  of  the  data  base.  A back-end  data  base  processor 
would  be  responsible  for  all  of  the  data  base  functions  that  are  normally 
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accomplished  in  the  main  computer  (Ref  4:1197).  Representatives  from 
the  Modeling  Branch  (DPMDDA)  at  the  AFMPC  requested  that  a back-end  data 
base  processor  model  be  developed  to  analyze  and  evaluate  different  cost 
and  configuration  alternatives  using  a back-end  data  base  processor  for 
data  base  management. 

Current  Knowledge  and  .Sources  of  Information 

Back-end  data  base  processors  are  relatively  new  to  the  world  of 
data  management.  The  majority  of  the  information  available  in  this  area 
can  only  be  found  in  recent  journal  articles  or  research  papers.  The 
information  about  the  AFMPC  data  base  system  is  not  located  in  any  single 
source  that  can  be  identified.  The  specific  details  are  spread  throughout 
three  different  areas:  (1)  government  publications,  (2)  AFMPC  programs, 
and  (3)  the  minds  of  different  individuals  assigned  to  the  AFMPC. 

Journal  articles  and  research  papers  were  obtained  from  professional 
organizations,  libraries,  and  the  Defense  Documentation  Center  (DDC) . The 
government  publications  were  obtained  through  normal  Air  Force  publication 
distribution  channels.  Personal  interviews  with  the  individuals  from  the 
Data  Management  Division  at  the  AFMPC  were  conducted  on  three  different 
trips  to  Randolph  AFB.  These  individuals  were  selected  so  that  they  could 
provide  a complete  picture  of  the  data  management  system  at  the  AFMPC. 

An  AFMPC  working  group  established  in  late  1977  also  provided  a large 
amount  of  useful  information  that  is  reflected  in  this  paper. 

Assumption  (Ref  3) 

The  amount  of  data  maintained  in  the  AFMPC  data  base  files  will  not 
decrease  significantly  in  the  forseeable  future.  It  will  either  stay 
about  the  same  or  increase  in  size. 
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Justification.  The  size  of  the  active  force  may  fluctuate  slightly, 
but  those  records  involved  will  be  transferred  from  one  file  to  another 
or  new  records  will  be  added  to  the  existing  files.  In  addition,  the 
number  of  items  maintained  in  each  record  has  increased  steadily  over  the 
years . 

Standards 

No  standards  have  been  identified  at  the  present  time,  however,  in 
any  follow-up  study  they  will  be  essential.  This  study  will  highlight 
a few  standards  that  should  be  considered  in  any  future  study. 

Scope 

The  magnitude  of  this  problem  is  such  that  it  cannot  be  completely 
covered  in  a single  thesis.  This  thesis  is  designed  to  provide  the 
foundation  for  the  development  and  evaluation  of  a model  of  a back-end  data 
base  processor  configuration  for  the  AFMPC.  The  complete  study  requested 
can  be  divided  into  different  steps,  as  follows: 

(1)  Describe  the  current  system,  the  back-end  concept,  the  general 
data  base  requirements,  and  outline  a course  of  action. 

(2)  Identify  and  document  the  detailed  requirements  of  the  system. 

(3)  Develop  a document,  i.e.  a handbook  or  user's  guide,  that  more 
explicitly  outlines  the  interface  required  between  the  ADDS  and 
a back-end  data  base  processor. 

(4)  Complete  an  evaluation  of  cost  alternatives  and  system  per- 
formance based  upon  different  hardware  configurations 

This  thesis  changed  from  a requirements  analysis  study  to  a problem 
analysis  study  and  will  cover  Step  fl ) and  provide  some  thoughts  for 
consideration  in  the  other  Steps.  The  complete  study  is  a "blue  sky" 
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project  and  as  such  it  does  not  have  a projected  deadline. 


Approach 

The  author  originally  planned  to  complete  Steps  1 and  2 and  had 
planned  to  use  "Structured  Analysis"  (SA)  in  Step  2 to  define  the  functional 
requirements  of  the  system.  This  is  an  analysis  technique  developed  by 
SOFTHCH,  Inc  (Ref  5 and  6)  that  uses  a topdown  approach  to  analyze  problems 
and  define  requirements.  Tv:o  different  models  are  developed  during  the 
use  of  this  analysis  technique:  (1)  an  activity  model,  and  (2)  a data  model. 
Normally,  the  activity  model  is  developed  first.  These  models  are  designed 
by  beginning  at  an  abstract  level  consistent  with  the  requirements  and 
desired  viewpoint  of  the  problem.  Then  the  abstract  level  is  broken  into 
three  to  six  sub-blocks,  which  may  in  turn  be  subdivided  further  until  the 
desired  amount  of  detail  is  obtained.  These  models  highlight  the  inter- 
action between  "activities"  and  "data"  by  looking  at  these  items  as  "controls 
"inputs",  "outputs",  or  "mechanisms".  The  data  model  is  used  primarily  to 
point  out  discrepancies  and  verify  the  activity  model.  As  these  models 
are  developed,  a "reader"  or  "readers"  crosscheck  the  validity  and  logic, 
of  the  models.  This  is  done  to  insure  that  the  models  are  accurate  ar.i  under 
standable.  Due  to  the  time  limitation  for  thesis  completion.  Step  2 was  not 
finished  and  the  SA  models  that  were  developed  were  incomplete.  Consequently 
they  are  not  included  with  this  thesis. 

This  thesis  is  divided  into  six  main  sections.  Chapter  1 provides 
background  information,  a broad  perspective,  and  the  rationale  for  this 
study.  Chapter  II  outlines  the  environment  within  which  a back-end  data 
base  processor  will  be  utilized.  It  contains  discussions  about  the 
organization,  the  hardware,  the  software,  and  the  data  files.  Chapter  III 
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contains  a review  of  the  back-end  data  base  processor  concept  and  some 
potential  advantages  and  disadvantages.  Chapter  IV  describes  the  general 
system  requirements  which  are  divided  into  functional  requirements  and 
basic  system  requirements.  In  Chapter  V,  the  results  of  this  investigation 
are  presented.  This  includes  (1)  the  effort  involved,  (2)  a plan-of- 
attack  that  is  established  for  future  studies,  and  (3)  a discussion  of  a 
back-end  system  for  the  AFMPC.  Chapter  VI  contains  a conclusion  and  some 
comments  about  any  future  studies  plus  a short  discussion  about  the  utility 
of  SA  during  this  investigation.  First,  however,  it  is  important  to 
understand  the  current  system  environment  which  is  discussed  in  the  next 
chapter. 
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II  System  Environment 

Organization 

General . Personnel  resource  management  is  affected  by  the  policies 
and  decisions  of  the  President,  Congress,  Department  of  Defense,  Head- 
quarters Air  Force,  major  command  headquarters  (MAJCOM) , base,  and 
subordinate  levels.  The  AFMPC,  as  the  agency  responsible  for  personnel 
management,  must  be  responsive  to  these  policies  and  decisions. 

Structure . The  AFMPC  is  a Special  Operating  Agency  (SOA)  located  at 
Randolph  AFB,  Texas,  and  is  commanded  by  a general  officer,  currently 
Major  General  L.  W.  Svendsen,  Jr.,  who  is  also  the  Assistant  Deputy  Chief 
of  Staff/Personnel  for  Military  Personnel.  At  the  AFMPC  there  are  four 
Directorates,  four  "Assistants  for",  and  three  specialist  offices  that 
are  directly  involved  with  the  five  functional  areas  of  personnel  management 
(Figure  1).  In  addition,  there  is  an  administrative  directorate,  a 
squadron  administrative  section,  and  the  Personnel  Data  Systems  Directorate 
(DPMD).  There  are  approximately  2000  people  assigned  to  the  AFMPC  and 
nearly  800  are  assigned  to  DPMD.  DPMD  is  divided  into  four  divisions; 
two  offices,  and  two  liaison  offices  subordinate  to  the  Requirements 
Management  Division  (DPMDQ)  (See  Figure  2). 

The  Directorate  of  Personnel  Data  Systems  (DPMD),  according  to  the 
USAFPP,  is  "responsible  for  providing  ADP  support  to  personnel  functions 
in  the  most  cost  effective  method  possible"  (Ref  7:3-1).  DPMD  consists  of 
four  Divisions;  two  "offices",  and  two  liaison  offices  subordinate  to  one 
of  the  divisions.  The  Computer  Operations  Division  (DPMDB)  is  responsible 
for  managing  and  operating  the  central  system  facility.  They  operate  the 
host  systems  and  process  the  system  activities  in  accordance  with  schedules 
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that  are  prepared  by  the  Systems  Operations  Division  (DPMDO) . DPMDO 
prepares  the  system  schedules  and  acts  as  a liaison  between  the  personnel 
technicians  (personnel  managers)  and  the  computer  system.  They  schedule 
computer  activity  based  upon  the  needs  of  the  personnel  technicians.  The 
Systems  Development  and  Support  Division  (DPMDD)  is  responsible  for  soft- 
ware development,  and  maintenance  for  the  Advanced  Personnel  Data  System 
(APDS  II).  The  Requirements  Management  Division  is  responsible  for 
developing  and  analyzing  current  and  future  personnel  ADP  requirements  for 
the  Air  Force.  The  two  liaison  offices  and  the  Washington  Area  ADP  Support 
Office  (DPMDW)  coordinate  their  personnel  management  requirements  with 
DPMD.  The  Standards  Application  Office  (DPMDF.)  is  responsible  for 
publishing  and  monitoring  AFMPC  ADP  standards,  monitoring  and  evaluating 
system  performance,  and  completing  periodic  systems  analysis. 

Policies.  Change  is  a "way  of  life"  in  personnel  management  for  the 
Air  Force.  National  policy  affects  defense  posture,  which  affects 
Federal  Fiscal  policy  and  budget  management,  which  affe  s the  force 
structure  and  military  hardware.  This  fact  causes  changes  that  arc 
reflected  in  the  management  of  personnel  resources.  In  addition,  Air 
Force  people  and  their  characteristics  are  constantly  changing  because  of 
promotions,  training,  assignments,  separations,  enlistments,  and  many  other 
reasons.  DPMD,  with  ADP  management  responsibility  for  the  Air  Force, 
must  develop  and  maintain  a computer  and  data  management  system  that  is 
responsive  to  these  changes. 

Personnel  assigned  to  DPMD  have  a very  strong  "mission"  motivation 
toward  that  goal  with  an  attitude  of  "We  will  do  it"  and  not  an  attitude 
of  "Can  we  do  it".  This  has  required  long  work  days  during  some  periods, 
and  it  is  also  reflected  in  the  development  of  the  data  management  system 
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and  in  hardware  procurement . 

In  the  author's  opinion,  the  data  management  system  has  evolved 
through  functional  consolidation/centralization  and  has  not  been  developed 
as  a functionally  integrated  data  management  system.  Because  of  the  source 
and  ever-changing  nature  of  personnel  management  requirements,  the  APDS 
has  evolved  on  an  "as  needed"  basis  in  lieu  of  being  developed  from  a 
functionally  cohesive,  top-down  perspective.  Any  system  developed  in 
this  manner  is  prone  to  have  various  kinds  of  inefficiencies,  such  as  over- 
lapping or  ill-defined  functions.  If  the  current  functional  requirements 
of  the  system  had  been  known  prior  to  its  orgin,  the  system  could  have 
been  built  with  a top-down  perspective.  However,  the  system  requirements 
are  continually  changing  because  personnel  management  policies  change  and 
new  decisions  are  made.  This  makes  the  system  extremely  difficult  to 
analyze  in  terms  of  a functional,  top-down  perspective. 

This  system  works  extremely  well  from  a "mission"  point  of  view,  but 
the  author  has  some  resei'vation  about  the  functional  cohesiveness  and 
effeciency  of  the  system.  System  efficiency  does  not  seem  to  be  of  great 
concern  to  many  people,  and  this  seems  to  promote  the  feeling  that  "If 
we  can't  do  it  with  what  we  have,  we  will  buy  more,  different,  or  larger 
units."  In  the  author's  opinion,  the  solution  is  to  study  and  analyze 
the  personnel  management  system  and  document  its  functional  requirements 
even  though  this  will  take  a large  amount  of  time  and  effort. 

Hardware  Configuration 

Network.  Tha  Advanced  Personnel  Data  System  (APDS)  is  a large 
hardware  network  with  the  central  site  located  at  Randolph  AFB,  Texas. 

The  central  site  is  linked  to  all  military  and  civilian  personnel  centers 
at  base  level,  MAJCOM  level,  and  Headquarters  Air  Force.  In  addition, 
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the  central  site  is  linked  to  the  recruiting  centers  through  the  PROMTS 
network.  Appendix  I contains  a set  of  communications  network  figures' 
that  were  extracted  from  Reference  2.  The  central  sice  is  also  linked 
to  the  Air  Reserve  Personnel  Center  (ARPC),  the  Air  Force  Accounting 
and  Finance  Center,  the  National  Guard  Bureau,  and  to  the  Civil  Service 
Commission . 

The  communications  network  is  serviced  through  dedicated  telephone 
lines  and  AUTODIN  circuits.  By  FY  1981,  all  dedicated  circuits  are  to  he 
released  and  communications  support  will  be  provided  by  AUTODIN  II.  There 
are  two  types  of  remotes  connected  to  the  network;  (1)  Query/Response 
terminals  and  (2)  Remote  Job  Entry  (RJE)  terminals.  The  query/response 
terminals  are  polled  for  service  and  the  RJE  terminals  must  signal 
the  central  site  for  service.  The  APDS  uses  three  different  telecommuni- 
cations techniques;  (1)  multiplexing,  (2)  multipointing,  and  (3)  point-to- 
point.  The  link  between  Randolph  AFB  and  Bolling  AFB  is  the  only  encrypted 
link,  and  it  is  conditioned  to  handle  material  that  is  classified  SECRET 
or  lower.  The  APDS-MAJCOM  project,  completed  in  1977,  has  added  more  than 
100  additional  terminals  to  the  network.  Annex  B of  DOD  Directive  4630.1 
contains  more  detailed  information  about  APDS-MAJCOM.  Currently,  there  are 
more  than  500  terminals  connected  to  the  APDS  communications  network. 

Central  Site.  The  central  site  at  the  AFMPC  has  two  Burroughs 
B-6700  computer  systems  which  are  the  nucleus  of  the  APDS  system.  In 
addition,  there  is  a Honeywell  6040  (H-6040)  that  is  used  for  microform 
processing,  an  AUTODIN  terminal  (owned  and  operated  by  the  Air  Force 
Communications  Service),  and  miscellaneous  other  special  purpose  equipment. 
Appendix  II  lists  the  APDS  hardware  configuration  as  of  15  October  1977, 
and  it  includes  the  off-station  remote  devices.  Burroughs  B-3500 
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computers  at  base  level  and  Honeywell  GOOD  computers  at  MAJCOM  level 
are  linked  to  the  central  site  through  telephone  and  AUTODIN  circuits 
and  support  personnel  management  functions  at  their  respective  levels. 

The  remaining  hardware  discussion  will  be  restricted  to  the  two  B-6700 
systems  since  they  are  the  nucleus  of  the  APDS,  and  they  manage  and  process 
all  of  the  personnel  data  at  the  AFMPC. 

The  B-6700  is  a large,  third -generation  computer  that  is  designed 
for  a multiprogramming  and  multiprocessing  environment  (References  8 and 
9 contain  detailed  information  on  the  B-6700).  The  "A"  and  "B"  B-6700 
systems  are  both  configured  with  three  central  processors  (the  maximum 
possible)  and  a 5 MHz  system  clock  (the  fastest).  The  B-6700  is  designed 
to  support  high-order- languages  (HOLs)  efficiently,  especially  ALGOL.  It 
is  a stack  oriented  machine,  and  it  assigns  an  area  of  memory  to  each 
program  for  use  as  a stack.  While  a program  is  executing,  four  registers 
in  the  processor  serve  as  the  top  of  the  stack  and  are  linked  by  hardware 
to  the  remainder  of  the  stack  in  memory.  Arithmetic  and  logical  operations 
are  performed  with  a Polish  stack,  which  allows  data  values  and  storage 
pointers  to  be  pushed  onto  the  stack  and  then  popped  off  as  operands  are 
needed  or  values  are  stored.  There  are  two  states  of  processor  operation, 
"control"  and  "normal".  "Control"  is  used  for  executing  privileged 
instructions  and  is  reserved  for  operating  system.  "Normal"  is  used  for 
regular  instruction  execution.  Interrupts  may  be  generated  internally  by 
the  processor  or  externally  by  some  device.  Prior  to  servicing  an 
interrupt,  all  critical  registers  are  saved  on  the  stack  and  a link  is 
established  to  insure  that  the  processor  returns  to  the  proper  location. 
Memory  protection  is  provided  in  two  ways;  (1)  by  comparing  memory 
addresses  to  program  boundary  registers,  and  (2)  by  using  control  bits  to 
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to  protect  code  and  words  which  define  memory  areas.  Consequently, 
programs  cannot  modify  their  own  code. 

Memory.  There  are  two  different  size  core  modules  available  for 
the  B-6700,  one  with  16K  words  and  the  other  with  65K  words.  Both  sizes 
arc  utilized  at  the  AFMPC.  The  "A"  system  contains  703K  words,  and  the 
"B"  system  contains  524K  words.  The  memory  access  times  vary  from  770 
nanoseconds  to  1600  nanoseconds.  Each  memory  word  consists  of  48  infor- 
mation bits,  a parity  bit,  and  three  control  bits  that  identify  the  word 
as  code,  data,  or  descriptor.  The  processors  in  each  system  are  connected 
to  their  respective  memory  modules  by  a memory  bus.  The  memory  bus  contain 
20  address  bits,  6 control  bits,  and  52  information  bits.  The  memory 
modules  operate  independently,  and  they  check  every  address  on  the  bus. 
Memory  interleaving  is  possible  on  the  B-6700  by  using  a pluggable  jumper. 

Input/Output  Processors  and  Peripherals . Each  system  has  two  I/O 
processors  which  can  be  connected  to  as  many  as  20  peripheral  units  The 
I/O  processors  are  linked  to  the  central  processors  by  the  scan  control 
bus.  A control  bit  is  passed  between  the  processors  to  restrict  access 
to  the  bus.  A processor  may  only  use  the  bus  when  it  has  the  control  bit. 

Data-switching  channels  link  the  peripheral  devices  to  the  main 
memory  and  are  assigned  to  a peripheral  control  by  the  I/O  processor 
when  I/O  is  initiated.  There  are  ten  data-switching  channels  with  each 
I/O  processor  on  the  "A"  system.  This  system  has  two  separate  peripheral 
control  busses,  and  this  prevents  the  I/O  processors  from  using  devices 
that  are  not  on  the  same  bus  as  the  I/O  processor.  "Exchanges"  for  tape 
drives  and  disk  drives  allow  the  peripheral  control  units  to  work  with 
any  device  on  the  "exchange".  One  disk  "exchange"  is  shared  between  the 
"A"  and  "B"  systems,  and  this  allows  the  two  systems  to  access  common  packs 
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Data  Communications.  System  "A"  has  four  data  communications 
processors  (DCPs),  and  system  "B"  has  two  DCPs  that  interface  with 
their  respective  I/O  processors.  Adapters  provide  the  logic  that  is 
needed  to  interface  a DCP  with  a data  set  or  communications  line.  The 
basic  system  architectures  for  the  "A"  and  "B"  system  are  outlined  in 
Figure  3 and  4.  More  detailed  information  can  be  found  in  Burroughs 
Technical  Manuals  and  in  documentation  maintained  by  DPMDB  at  the  AFMPC. 

Software  (Ref  8 through  14) 

General . There  are  three  categories  of  software  on  the  B-6700; 
the  Master  Control  Program  (MCP)  which  is  the  operating  system, 
compilers,  and  data  communications  software  (Ref  8 and  9).  The  MCP  is 
divided  into  three  levels;  a kernel  for  processing  interrupts  is  the 
highest  level,  resource  allocation  is  the  next  level,  and  the  utility 
functions  are  at  the  lowest  level.  The  kernel  is  capable  of  reconfiguring 
the  system  in  13  different  wrays  in  the  event  the  system  fails.  If  a 
suitable  configuration  is  found,  the  system  is  reinitiated  and  restarted 
from  a suitable  checkpoint.  Main  memory  is  allocated  by  variable  length 
segments,  and  the  segments  are  removed  on  a least-recently-allocated 
algorithm.  Segments  may  be  shared  by  tasks  to  facilitate  the  use  of 
compilers  and  some  MCP  routines.  Resource  allocation  comprises  the 
largest  portion  of  the  MCP's  activities.  The  resources  are  assigned  by 
tasks  which  can  in  turn  be  divided  into  sub-tasks  to  facilitate  parallel 
processing.  Main  memory  is  also  allocated  in  "working  sets",  which  limits 
the  number  of  segments  a task  can  have  in  core.  The  "working  set"  size 
is  determined  at  compilation  time  and  is  updated  by  the  MCr  to  maximize 
system  efficiency.  Memory  in  the  B-6700s  at  the  AFMPC  is  divided  into 
two  separate  areas  to  support  on-line  users  and  batch  respectively.  This 
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was  done  to  keep  the  on-line  users  (high-priority  activity)  from 
dominating  the  machine  resources  and  completely  disrupting  the  batch 
processing  activity.  Memory  protection  is  provided  by  using  (1)  stack 
and  stack  1 i » ; i t registers  to  identify  task  boundaries,  (2)  data  descriptors 
that  identify  the  base  address  and  the  size  of  each  data  block,  and  (3) 
a flag  hit  on  each  memory  word  to  identify  it  as  code  or  data. 

Trie  MCP  also  manages  the  I/O  devices.  It  maintains  device  status 
and  assigns  devices  as  needed  to  allow  efficient  machine  and  device 
utilization.  Output  can  be  "spooled"  to  disk  and  then  transferred  to  an 
output  device  to  improve  the  I/O  efficiency  of  the  machine.  Batch  jobs 
are  separated  into  six  different  queues  (stacks)  at  the  AFMPC  based  upon 
job  characteristics  (See  Table  2).  These  queues  contain  the  following 
information  about  the  job;  priority,  resource  requirements,  and  location 
of  code  segments.  The  queues  can  be  in  three  different  states:  priority, 
filler,  or  off,  with  queues  1 and  6 remaining  in  the  priority  state.  The 
other  queues  arc  adjusted  by  the  SUPERVISOR  program.  This  program  was 
written  by  personnel  at  the  AFMPC,  and  it  schedules  the  jobs  in  the  queues. 

Table  II.  B-6700  Input  Queues  (Ref  3) 

Queue  Types  of  Jobs 

1 Jobs  entered  from  the  operator's  console 

2 Production  jobs 

3 Recurring  daily  maintenance  runs  requiring 

an  overnight  turnaround 

4 Recurring  daily  maintenance  runs  requiring 

a daytime  turnaround 

5 Program  Development  jobs 

6 Promotion  board  support  jobs 
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After  the  priority  queues  are  empty,  the  SUPERVISOR  schedules  the  filler 
queues.  Batch  processing  is  routinely  scheduled  at  night  to  support  the 
heavy  on-line  processing  requirement  during  the  daytime. 


I 

Data  Management  System  II  (DMS  II)  is  a host  language  DMS  interface 
developed  by  Burroughs  that  can  be  used  by  either  batch  or  on-line  programs. 
DMS  II  provides  several  methods  for  retrieving  data;  can  be  used  to 
structure  a data  base;  and  also  provides  checkpoints  for  program  restarts 
after  hardware  malfunctions. 

Compilers/Languages.  The  following  high-order  languages  can  be  used 
on  the  B-6700;  ALGOL,  APL , COBOL,  FORTRAN  I,  and  PL/1.  Even  though  the 

1 B-6700  is  an  ALGOL  oriented  machine,  COBOL  is  the  most  commonly  used 

[ 

language  at  the  AFMPC.  There  are  a few  programs,  however,  that  use 
ALGOL  when  it  is  impractical  or  impossible  to  use  COBOL  to  produce  the 
desired  software. 

There  is  a,  locally  developed,  DFTAP  (acronym- source  unknown) 
preprocessor  that  is  used  to  convert  programs  written  in  a special 
analyst  language,  Decision  Logic  Tables  (DLTs),  to  COBOL  source  statements. 
The  analyst  software  is  comprised  of  many  DLTs  which  contain  logic 

|p 

routines  that  reflect  actions  and  conditions  contained  in  the  applicable 
directives  and  regulations.  Each  routine  is  identified  with  and  related 
to  a specific  transaction;  however,  the  routines  may  be  called  by  more 

* 

than  one  transaction.  The  DLT  software  is  used  by  the  General  Update 

j 

System  (GUS)  to  build  and  maintain  the  master  personnel  files  (MPFs). 

Section  3 in  Reference  10  documents  the  AFMPC  rationale  and  general 
procedures  for  using  DLTs. 

Data  Communications  Software.  Programs  and  routines  in  the  MCP  and 
f the  Data  Communications  Processor  (DCP)  share  tho  communications  control 
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functions.  Programs  for  the  DCP  are  produced  by  processing  iocal 
specification  punched  cards  containing  a terminal’s  characteristics 
through  the  Network  Definition  Language  compiler.  The  compiler  generates 
DCP  programs  for  the  user's  specific  terminal  configuration.  A message 
control  system  in  the  MCP  allows  messages  to  be  passed  between  programs 
operating  under  the  MCP  and  users  operating  on-line. 

Data  Files  (Ref  14).  There  are  many  files,  program  series, 
utilized  and  maintained  by  the  AFMPC.  Appendix  III  contains  a list  of 
files  and  file  codes  extracted  from  Reference  11  plus  a few  additional 
files  that  have  been  added  since  document  publication.  These  files  can 
be  divided  into  four  different  classes;  (1)  the  General  Update  System 
(GUS)  files  (the  MPFs),  (2)  other  subsystem  files,  (3)  extract  files, 
and  (4)  special-purpose  vrork  or  local-use  files.  The  extract  and  special- 
purpose  files  are  special-use  files  that  are  generally  small  and/or 
contain  data  that  is  transient  in  nature.  These  files  are  of  little 
interest  except  for  the  fact  that  they  do  exist  because  they  only  contain 
and/or  use  functional  data  that  is  duplicated  in  the  MPFs  and  subsystem 
files. 

The  MPFs  are  the  files  that  form  the  core  of  the  personnel  system. 

They  include  the  people  files,  a job/position  authorization  file,  and  a 
privacy  transaction  information  file  (Table  3).  These  files  are  updated 
and  maintained  by  the  General  Update  System  (GUS).  The  GUS  is  transaction 
oriented  and  utilizes  Transaction  Identification  Codes  (TICs)  to  identify 
the  procedures/transactions  written  in  the  DLT  language.  The  first  seven 
files  are  people  files  that  contain  personnel  records  and  divide  the 
records  into  groups  that  reflect  an  individual's  duty  status.  The  individual's 
Social  Security  number  is  the  key  used  to  access  records  on  these  files. 


Table  III . MPFs  and  Associated  File  Codes 


File  Code 

MPF  Title 

AA 

Active  Airman 

AG 

Guard  Airman 

AR 

Reserve  Airman 

BA 

Active  Officer 

BG 

Guard  Officer 

BR 

Reserve  Officer 

CA 

Civilian 

MD 

Manpower 

PR 

Privacy  Act  Tracking  System  (PATS) 

The  Manpower  file  is  used  to  monitor  and  manage  the  Manpower 
authorizations  (positions)  in  the  Air  Force.  A duty  designator  (AFSC)  is 
the  key  used  to  access  records  on  the  Manpower  file.  The  Privacy  Act 
Tracking  System  (PATS)  file  is  used  to  record  data  pertaining  to  "Privacy 
Act"  information  that  is  released  outside  the  personnel  management  system. 

The  other  subsystem  files  are  files  that  are  used  to  support  a 
specialized  personnel  management  function  or  functions.  The  subsystems 
may  update/process  a single  file  or  several  files  depending  upon  the 
function  of  the  particular  subsystem.  Table  4 identifies  some  of  the  more 
prominent  subsystems  and  their  processing  requirements.  The  files  updated 
and  maintained  by  these  subsystems  may  contain  information  that  is  also 
contained  on  an  MPF  and/or  other  subsystem  files  plus  any  functionally 
unique  information  that  is  required.  The  MPFs  and  other  subsystem  files 
are  updated/processed  at  varying  intervals  depending  upon  personnel 
management  requirements.  Some  files  are  updated/processed  several  times 
per  day  and  others  may  only  be  updated/processed  monthly.  Update  trans- 
actions are  collected  in  a transaction/update  file  that  is  processed 
against  the  applicable  file  at  the  desired  time.  Each  subsystem  has  its 
own  transaction/update  file.  These  updates  may  in  turn  precipitate  other 
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SOURCE:  Briefing  at  AFMPC,  Randolph  AFB,  Texas. 
S Sep  77  - Lt  Col  Nardi  (DPMDOD) 


SOURCE:  Briefing  at  AFMPC,  Randolph  AFB,  Tex; 
8 Sep  77  - Lt  Col  Nardi  (DFMDOD) 


other  transactions  that  must  be  processed  on  other  subsystems/files.  It 
can  be  several  days  or  more  before  the  effect  of  a-transaction  is  coinpletel 
reflected  in  all  files. 

The  interactions  and  relationships  between  files  are  very  complex 
and  not  well  documented.  Many  are  quite  obvious,  while  others  are  not 
so  readily  apparent.  The  author  was  shown  a diagram  very  similar  to 
Figure  5,  which  represented  the  subsystem  interfaces.  At  this  point, 
the  author  asked  "Which  of  those  subsystems/files  make  up  the  AFMPC 
data  base"?  The  answer  varied  depending  upon  who  answered  the  question 
and  their  perspective  at  the  time.  On  occasion  it  was  intimated  that  the 
MPFs  plus  as  many  as  16  subsystem  files  might  comprise  the  data  base.  It 
was  difficult  for  the  author  to  get- a consistent  picture  of  the  data 
base,  but  the  MPFs  were  included  in  all  discussions  about  the  data  base 
system.  So  for  the  purpose  of  this  paper,  the  data  base  is  considered  to 
be  the  MPFs  identified  in  Table  3.  As  a minimum,  the  back-end  data  base 
processor  concept,  must  support  these  files  since  they  form  the  nucleus  of 
the  personnel  data  system. 

There  are  several  different  retrieval  systems  used  against  these 
AFMPC  files.  The  more  commonly  used  retrieval  systems  are  ATLAS,  SURF, 
WINQ,  WSMM,  and  AIRS.  ATLAS  is  a batch,  multiple  record,  retrieval 
system  that  can  be  used  on  any  file  that  is  described  by  the  standard 
APDS  Rata  Descriptor  Table  (DDT).  SURF  is  a single  record  retrieval 
system  for  use  on-line.  A single  personnel  record  is  retrieved  by  using 
a Social  Security  Number  (SSAN)  key  and  then  the  data  is  reformatted  as 
desired  by  the  user.  WINQ  is  both  an  on-line  and  a batch  retrieval  system 
that  is  capable  of  multiple  record  retrieval  from  any  GUS  file  or  free- 
formated  file.  . is  capable  of  producing  a variety  of  reports  in 
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several  different  formats.  WSMM  is  a specialized  retrieval  system  that 
is  used  to  provide  weapons  system  managers  with  on-line  access  to  weapon 
system  data  on  the  Active  Officer  file.  AIRS  is  another  specialized 
retrieval  system  that  is  used  to  obtain  and  summarize  Active  Airman  manning 
statistics.  More  detailed  information  is  available  in  Chapter  9 of 
Reference  12  and  through  the  applicable  programmers  in  DPMDD  at  the  AF.'iPC. 

This  chapter  has  described  the  environment  within  which  any  new  data 
management  system  will  be  developed.  The  next  chapter  contains  a descrip- 
tion of  the  back-end  data  base  processor  concept.  It  is  a relatively  new 
concept  in  data  management  with  some  distinct  advantages  and  capabilities 
that  look  promising  to  the  AFMPC. 
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Ill  Back-End  Data  Base  Processor  Concert 


This  section  of  the  report  contains  a discussion  of  the  back-end 
data  base  processor  concept  which  includes  a discussion  of  some  potential 
advantages  and  disadvantages  of  the  concept. 

General  (Ref  15  and  16  ) 

The  world  of  information  management  is  changing  rapidly.  In  an  effort 
to  effectively  m-nage  limited  resources,  commercial  and  government  organi- 
zations are  frequently  expanding  their  need  for  management  information. 

This  lias  caused  an  increase  in  the  kinds,  quantity,  and/or  complexity  of 
the  data  that  is  maintained  in  their  respective  data  base  systems.  As  the 
user's  information  needs  have  increased,  so  has  the  proliferation  of  data 
base  systems  increased . Many  different  data  base  systems  have  been 
developed  to  meet  the  information  requirements  of  the  many  different 
users.  Appendix  B in  Reference  17  lists  more  than  90  different  data  base 
systems  and  to  paraphrase  the  author  "these  systems  are  historically 
significant  or  potential  sources  for  further  study  and  experimentation." 
These  systems  were  developed  in  relative  isolation,  and  as  a result, 
there  is  little  standardization  between  them,  especially  in  the  following 
areas:  hardware  design,  file  structure,  data  base  software,  and  terminology. 
Standards  in  these  areas  have  been  nearly  non-existent.  The  CODASYL  Data 
Base  Task  Group  (DBTG)  has  developed  a high  level  data  base  management 
language,  which  is  designed  to  provide  some  uniformity  and  possibly  be  an 
industry  standard  for  data  base  systems. 

Many  recent  developments  in  several  areas,  especially  computer 
hardware;  i.e.  microprocessors,  minicomputers,  and  memory  devices;  have  a 
great  potential  to  improve  data  base  management  systems.  Hardware 
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technological  advances  and  decreasing  hardware  costs  are  making  it 
feasible  to  investigate  several  other  concepts  for  data  base  management. 

In  addition,  the  advances  in  hardware  give  the  systems  designers  greater 
flexibility  in  system  configuration  and  also  make  it  practical  to  employ 
new  concepts  in  areas  like  data  base  file  structure  design  and  data  base 
file  management  software.  One  of  the  new  concepts  in  system  configuration 
involves  tiie  use  of  a back-end  data  base  processor  for  data  base  management. 

Back-End  Data  Base  Processor 

The  back-end  processor  is  similar  to  the  front-end  processor  which 
serves  as  the  interface  between  the  host  computer  and  the  different  input 
devices.  The  back-end  processor  is  the  interface  between  the  host 
computer  and  its  data  base,  and  it  accomplishes  the  specialized  data  base 
functions  that  are  normally  handled  by  the  host  computer.  Figure  6 is  a 
block  diagram  of  a basic  back-end  data  base  processor  system  configuration. 
Figures  7,  8,  and  9,  depict  more  complex  configurations  of  back-end  data 
base  processor  systems.  The  back-end  processor  con  be  anything  from  a 
minicomputer  to  a large  scale  computer.  It  can  be  a conventional  general- 
purpose  computer  or  it  can  be  a highly  specialized  computer,  a data  base 
computer  (DBC),  that  is  specifically  designed  to  support  the  data  base 
management  functions.  The  functions  that  a back-end  processor  will  perform 
depends  to  some  degree  on  the  configuration  of  the  system  that  it.  supports. 
It  could  support  a single  host,  a dual  host,  or  other  multiple  host 
configurations.  The  back-end  processor  might  be  one  of  several  back-ends 
that  support  a single  data  base  system  or  multiple  data  base  systems.  It 
might  be  utilized  as  one  of  many  data  base  processors  that  support  a network 
of  distribution  data  basis.  The  technological  advances  in  the  areas  of 
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Figure  6.  A basic  back-end  data  base  processor  configuration 


of  hardware  design,  hardware  manufacture,  memory  systems,  data  base 
systems,  data  structures  and  file  organization,  and  communications 
systems;  contribute  to  the  practical  feasibility  of  using  a back-end 
processor  at  the  AFMPC. 

Advantages 

General . There  are  several  potential  advantages  that  have  been 
noted  by  different  sources  (Ref  15  and  16).  These  advantages  are 
discussed  below  along  with  an  occasional  observation  on  the  significant 
advantage  to  the  Air  Force  personnel  data  management  system. 

(1)  Economy  Through  Specialization  (Ref  16:6-36).  By  selecting 
the  proper  hardware  and  software  for  the  back-end  processor,  the  system 
can  be  tailored  to  meet  the  data  management  requirements  of  the  AFMPC. 

The  specialized  purpose  of  the  back-end  processor  eliminates  the  require- 
ment for  a large  gend-ral-purpose  operating  system  and  allows  the  operating 
system  to  be  designed  to  support  the  data  management  function.  This  in 
turn  simplifies  the  interface  between  the  operating  system  and  the  data 
management  system.  This  leads  to  economics  in  the  areas  of  (1)  smaller 
on-line  core  requirements,  (2)  simpler  programs  which  would  require  less 
core  and  less  processing  time,  (3)  smaller  development  costs,  and  (4) 
shorter  development  cycles.  A specialized  data  base  computer  (DBC)  would 
not  need  all  of  the  sophisticated  capabilities  of  the  traditional  computer, 
i.e.  floating  point  operations,  high-speed  multiply  and  divide,  and  circuits 
to  handle  a wide  variety  of  peripherals.  A specialized  processor  with 
an  efficient  encode-decode  capability  will  allow  the  data  to  be  compressed 
with  encoding  techniques  which  will  reduce  data  base  storage  requirements. 
The  implementation  of  a specialized  data  base  computer  (DBC)  is  discussed 
in  References  15,  and  18  through  24. 
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(2)  Shared  Data  (Ref  16:6-36/575).  There  is  a potential  to  share 


data  between  computer  systems  in  lieu  of  creating  and/or  maintaining 
duplicate  information  in  different  systems.  The  maintenance  of  the  sane 
data  in  different  files  or  different  systems  can  cause  inconsistencies  in 
data  if  the  updates  to  the  files  are  not  coordinated  or  synchronized  in 
some  way.  Reference  15:1197  points  out  that  the  "Datacomputer"  is 
functioning  as  a loosely  coupled  back-end  processor  through  the  Arpanet 
and  it  maintains  information  for  several  different  computers.  A 
distributed  data  base  system  could  be  developed  by  using  several  back-end 
processors  at  data  base  nodes  and  linking  these  nodes  together. 

(3)  Low  Storage  Cost  (Ref  15:1197  and  1S:74).  The  storage  cost  per 
byte  can  be  reduced  by  pooling  the  storage  requirements  for  several 
computers  and  utilizing  more  economical  high-volume  storage  devices. 
Because  of  the  volume  of  data  that  is  maintained  by  the  AFMPC  in  their 
data  base  system,  it  may  not  be  prudent  to  pool  requirements  except 
within  the  Air  Force  personnel  system.  At  the  present  time,  the  AFMPC  is 
utilizing  several  disk  packs  to  hold  their  MPFs,  and  until  storage  device 
have  a greater  capacity  for  storing  and  managing  data  there  does  not 
appear  to  be  any  need  for  the  AFMPC  to  pool  storage  requirements  with  any 
other  system (s). 

(4)  Compatibility  and  Uniformity  (Ref  15:1197).  There  may  be  many 
different  computers  spread  throughout  a large  corporation  or  government 
organization.  These  computers  quite  frequently  arc  different  systems 
(produced  by  different  manufacturers)'  and  the  transfer  of  information 
between  them  is  difficult  because  of  the  differences  between  the  systems 
and  their  data  bases.  A back-end  data  base  processor  will  alleviate  this 
problem  as  long  as  the  computers  (hosts)  communicate  with  either  a common 
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back-end  processor,  or  an  identical  processor,  and/or  use  a common  data 
base  language  in  the  interfaces  between  the  hosts  and  the  back-end 
processor  (s) . 

(5)  Data  Base  Protection  (Ref  16:6-38-/577).  Both  the  security 
and  reliability  of  the  data  base  can  be  improved  by  using  a back-end 
processor.  With  a single,  centralized  link  to  the  data  base,  the  security 
management  functions  can  be  localized  in  the  back-end  processor.  This 
single  link  should  reduce  the  potential  for  malicious  or  accidental  access 
to  the  data  base  and  reduce  the  possibility  of  any  unexpected  sneak 
paths,  and  subsequent  unauthorized  access,  to  the  data  through  another 
management  system  or  some  breach  of  the  memory  protection  system. 

Reliability  of  the  systems  and  data  base  could  be  improved  by  using  the 
host  and  the  back-end  to  cross-check  each  other  for  failures.  This  can 

be  accomplished  by  monitoring  messages  for  consistency  and  proper 
formatting.  If  a failure  in  the  host  occurs,  a "rollback"  could  be 
accomplished  through  the  use  of  an  audit  trail  of  data  base  changes 
maintained  in  the  back-end  processor.  The  back-end  could  be  restored  to 
a suitable  inactive  state  with  this  information  and  then  wait  for  the 
host  to  be  restarted.  The  host  can  stop  requesting  service  and  save  or 
hold  the  requested  transactions  until  the  back-end  can  accept  them. 

(6)  Data  Base  Management  for  New  Machines  (Ref  16:6-38/577). 

After  the  back-end  system  is  established  for  a given  host,  it  should 
simplify  the  development  of  a new  interface  for  a new/replacement  host 
computer.  A new  and  complete  data  management  system  would  not  have  to  be 
developed  for  the  new  host,  but  only  the  interface  with  the  back-end  would 
have  to  be  developed.  In  addition,  the  data  management  function  for  a 
single  host  could  be  handled  by  a smaller  computer,  possible  a minicomputer, 
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in  a back-end  configuration. 


(7)  Extended  Usefulness  of  Current  Systems  (Ref  15:1197).  If 
the  data  base  management  functions  can  be  withdrawn  from  an  overloaded 
system  or  systems  and  placed  in  a back-end  data  base  processor,  the 
workload  of  the  host(s)  could  be  reduced  enough  to  extend  the  usefulness 
of  the  host(s)  for  several  years.  This  would  also  allow  data  base 
processing  and  routine  processing  to  proceed  concurrently  and  would  also 
reduce  the  amount  of  core  required  in  the  host  to  support  data  base 
management.  A common  back-end  processor,  utilized  by  two  or  more  systems, 
can  serve  as  a link  between  the  hosts  and  their  respective  data  bases. 

This  may  eliminate  the  need  to  carry  duplicate  copies  of  information  in 
two  different  files  and/or  systems. 

Disadvantages 

(1)  Cost  of  an  Additional  Machine  (Ref  16:6-58/577,  6-39/573). 

A second  machine  wTill  cost  money  and  also  require  some  effort  to  implement 
the  interfaces.  The  cost  of  the  second  machine  will  have  to  bo  evaluated 
in  light,  of  the  alternatives  to  determine  if  it  is  practical  to  obtain  the 
additional  computer.  However,  the  use  of  a back-end  may  permit  the  use  of 
a smaller,  less  expensive  host  or  preclude  the  purchase  of  a larger  more 
expensive  host.  Procurement  is  another  potential  problem  area;  since  the 
two  computers,  the  back-end  and  the  host,  would  probably  be  purchased  under 
separate  contracts.  The  contracting  problems  would  be  increased  because 
of  the  procurement  and  the  increased  requirements  for  items  like  operator 
training,  maintenance  procedures  and  support,  interface  designs,  and 
systems  programming  support. 

(2)  Unbalanced  Resources  (Ref  16:6-39/578).  The  addition  of  the 
back-end  could  lead  to  an  unbalance  in  system  resource  utilization.  The 
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host  may  be  busy  while  there  is  a large  amount  of  idle  time  on  the  back- 
end or  vice  versa.  Hither  of  these  situations  may  make  the  economics  of 
utilizing  a back-end  processor  questionable,  if  not  unacceptable.  It  may 
be  possible  to  increase  the  workload  of  the  under  utilized  system  by  sharing 
it  with  another  user.  The  unbalanced  condition  could  be  continuous,  random, 
or  even  oscillate  between  the  host  and  the  back-end.  The  exact  nature  of  the 
unbalance  could  easily  impact  the  decision  of  how  to  solve  the  problem 
of  unbalanced  resource  utilization. 

(3)  Response  Time  Overhead  (Ref  16:0-39/578).  In  a back-end 
processor  system  configuration,  the  response  time  could  be  degraded  since 
the  access  request  must  go  from  the  host  to  the  baek-end,  followed  by 
the  data  retrieval/update,  and  then  returned  to  the  host.  Two  steps  have 
been  added  in  the  access  sequence  which  could  quite  reasonably  downgrade 
response  time.  However,  if  the  back-cnd  is  a data  base  computer  (DBG) 
that  is  specifically  designed  to  support  data  base  management  and  the 
data  base  is  structured  for  efficient  access,  including  both  update  and 
retrieval,  the  response  tine  could  possibly  be  improved  instead  of 
degraded. 

In  this  portion  of  the  thesis,  the  back-end  concept  was  reviewed  and 
some  of  its  advantages  and  disadvantages  were  discussed.  In  the  following 
chapter,  the  personnel  management  functions  (functional  requirements)  are 
described  and  followed  by  a discussion  of  the  associated  basic  system 
requirements.  The  basic  system  requirements  are  discussed  with  a view 
toward  the  utilization  of  a back-end  data  base  processor  system  at  the  AFXPC. 
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IV  General  Requirements 


effective  personnel  management  is  the  "mission"  of  the  AFMPC.  The 
data  management  system,  first  and  foremost,  must  support  this  "mission". 
Requirements  described  in  this  chapter  are  divided  into  two  distinct 
categories;  (1)  functional,  and  (2)  system. 

In  this  chapter,  personnel  management  is  discussed  from  a top-down 
perspective.  The  viewpoint  for  this  discussion  is  a high-level  view  that 
looks  at  the  full  spectrum  of  personnel  management  functions.  This  point - 
of-view  was  selected  to  develop  a clear  picture  and  understanding  of  the 
relationships  between  the  different  functions  and  their  subfunctions. 

These  relationships  represent  interfaces  which  cause  many  of  the  file 
interactions  in  the  current  system.  The  different  personnel  management 
functions  and  responsibilities  are  addressed  i e this  chapter  as  "functional 
requirements",  since  the  system  exists  to  support  these  functions. 

The  personnel  management  functional  requirements  are  the  basis  for  the 
data  base  system  and  they  determine  what  informal!  n is  needed  in  the  data 
base.  They  also  dictate  what,  when,  and  how  the  data  base  information  is 
used.  Therefore,  it  is  essential  for  a system  designer  to  understand  the 
functional  requirements  and  their  impact  upon  the  system  structure  and 
design. 

The  physical  structure  and  design  of  the  system  are  determined  by 
the  basic  system  requirements.  These  requirements  arc  general  design 
considerations  that  are  used  to  determine  the  capability  ani  feasibility  of 
any  AFMPC  data  management  system.  They  are  derived  from  the  defined 
functional  requirements,  the  desired  performance  characteristics,  and/or 


40 


the  known  design  limitations.  The  basic  system  requirements  will  be 
discussed  after  the  functional  requirements  are  described. 

Functional  Requirement s 

The  following  discussions  are  based  upon  the  knowledge  and  under- 
standing obtained  from  the  personnel  directives  and  the  personal  interviews 
at  the  AFMPC.  These  discussions  are  presented  with  a top-down  perspective 
and  constitute  a starting  point  for  future  studies  in  this  area.  Personnel 
management  is  divided  into  five  different  functional  areas  which  must  be 
supported  by  the  AFMPC  data  management  system.  Figures  19  through  IS 
graphically  display  Air  Force  personnel  management  from  the  highest 
perspective.  Figure  10  is  the  very  top  view  and  includes  the  five  basic 
management  functions  of  personnel. 

(1)  Procurement . Procurement  is  the  process  of  obtaining  people  to 
fill  the  manpower  positions  in  the  Air  Force.  Figure  11  shows  a break- 
down of  the  procurement  function  into  sub-functions.  First,  the  desired 
orce  manning  is  determined  based  upon  the  Air  Force  mission  requirements 
and  it  is  structured  by  such  factors,  as:  educational  level,  skills,  sex, 
race,  age,  grade,  etc.  The  current  force  is  controlled  by  comparing  th: 
projected  force  manning  with  the  desired  force  manning  to  establish  the 
required  input  quotas.  The  projected  force  manning  is  determined  by 
adjusting  current  manning  with  force  attrition  statistics,  which  are 
determined  by  using  historical  data  and  projected  separation-date  information. 
Manpower  models  are  used  frequently  to  determine  the  impact  of  decisions 
and  policy  changes  on  manning  and  to  predict  future  manpower  requirements. 

The  manpower  needs  Cquotas)  of  the  Air  Force  are  filled  by  obtaining 
people  through  several  different  methods;  recruitment,  agmentation. 
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retention,  re-enlistment,  and  appointment  (direct  commission).  All  of 
these  functions  are  supported  by  the  personnel  information  and  the  job 
requirements  data  maintained  at  the  AFMPC, 

(2)  Training . There  are  three  major  categories  of  training,  which 

are:  (1)  Professional  Military  Training  (PME) , (2)  Technical  Training,  and 

(3)  Academic  Education.  This  function  is  sub-divided  into  four  lesser  func- 
tions (See  Figure  12).  People  are  screened  to  identify  training  cligibles 
and  to  meet  the  Air  Force  training  requirements.  These  eligibles  are  then 
matched  with  class  quotas  and  scheduled  for  training.  The  training  status 
of  the  students  is  monitored  to  determine  graduation  dates  and  the  availa- 
bility of  trained  resources.  To  support  these  functions,  it  is  necessary 

to  maintain  course- summary  data  and  coordinate  training  quotas.  Several 
different  files  are  currently  used  to  support  all  of  these  functions. 

There  is  a large  amount  of  data  interaction  between  the  training 
function  and  the  other  functions.  For  example,  the  class  schedules  have  to 
be  passed  to  the  assignments  and  procurement  functional  managers  so  they  can 
accomplish  their  jobs  effectively.  Class  schedules  and  course  completion 
dates  are  very  important  in  scheduling  assignments  and  enlistments.  As 
people  are  procured,  they  usually  need  some  form  of  training  and  many  other 
people  receive  assignments  that  require  some  form  of  specialised  training. 
Highly  qualified  individuals  are  selected  for  a professional  military 
education  (PME)  or  an  advanced  academic  education,  which  can  affect  their 
assignments  and  utilization  both  before  and  after  they  complete  the  education. 

(3)  Utilization.  The  Air  Force  must  utilize  people  to  accomplish 
its  mission  and,  consequently,  "utilization"  is  the  central  function  of 
personnel  management.  The  other  four  functions  support  the  Air  Force 
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requirement  to  use  people  and  are  important  because  they  affect  how 
efficiently  and  effectively  t he  personnel  resources  are  used.  Figure  Id 
displays  a breakdown  of  the  utilization  function  into  four  sub'-f unctions. 

People  must  be  properly  assigned  based  upon  their  skills  and  other 
job  qualifications,  if  they  are  going  to  be  utilized  effectively.  This 
requires  that  experience,  training,  and  educational  background  be  main- 
tained in  the  personnel  data  base  system.  An  individual's  assignment 
depends  upon  his  qualifications  and  the  available  job  vacancies  that  are 
caused  by  a change  in  mission  requirements,  separations , or  reassignment s . 
This  requires  that  a record  of  all  of  the  jobs  in  the  Air  Force  be  main- 
tained in  the  data  base  and  that  the  characteristics  of  each  job  be 
specified,  i.e.  job  qualifications  required,  status  of  the  job  (filled  or 
unfilled),  special  training  required,  job  title,  AFSC,  and  location.  To 
provide  a balanced  force  structure  the  AFMPC  maintains  an  active  Career 
Development  program  which  also  affects  personnel  utilization  and  adds  to  the 
quantity  of  data  that  must  be  maintained  by  the  AFMPC.  This  includes  the 
following:  career  broadening  information,  career  counseling  data,  and 
career  management  patterns.  There  are  certain  selected  assignments  that 
are  maintained  for  graduates  of  professional  military  schools  and  Air  Force 
sponsored  graduate  programs.  There  is  an  obvious  data  link  between  this 
function  and  the  other  personnel  functions. 

(4)  Sustainment . The  Air  Force  promotes  "espirit  de  corps"  and 
provides  motivation  to  its  employees  when  it  satisfies  the  function  of 
sustainment.  Figure  14  contains  a breakdown  of  this  function.  Items 
that  fall  into  the  area  of  sustainment  include:  personal  recognition  for 
achievements,  compensation,  and  promotion.  It  also  includes  providing  for 
the  welfare  and  needs  of  its  people,  i.e.  religious  and  medical  support. 
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Figure  13.  Personnel  Utilization. 


legal  assistance,  and  personal  affairs  counseling.  A large  variety  and 
quantity  of  data  must  be  maintained  in  the  AFMPC  to  support  this  function. 
This  includes  information  which  describes  the  individuals  performance, 
his  personal  characteristics,  and  his  personal  history. 

The  personnel  in  the  Air  Force  must  be  monitored  and  evaluated  to 
be  sure  that  they  are  properly  supported  and  rewarded  for  their  service. 
People  with  superior  performance  records  must  be  promoted  and  those  with 
distinctive  achievements  must  be  recognized  with  awards,  decorations,  and 
other  recognition  devices.  In  addition,  all  people  must  be  compensated 
for  their  Air  Force  service  and  this  requires  that  selected  accounting  and 
finance  data  be  maintained  and  forwarded  to  the  Air  Force  Accounting  and 
Finance  Center  at  Denver,  Colorado.  The  function  of  sustainment  also 
includes  monitoring  and  administering  the  "Equal  Opportunity"  programs 
plus  monitoring  the  conduct  and  discipline  of  the  Air  Force  employees. 

From  the  preceding  paragraphs,  it  is  quite  obvious  that  a large  amount 
of  the  data  maintained  in  the  data  base  is  useu  to  support  this  function. 
There  are  approximately  15  different  file  systems  that  support  this 
function  and  utilize  information  that  is  maintained  or  the  MPFs.  It  is 
quite  conceivable  that  at  least  one-fourth  of  the  information  of  the 
MPFs  is  used  to  support  the  function  of  sustainment  either  directly  or 
indirectly.  Sustainment  is  a very  important  function  that  spans  the 
personnel  life  cycle  from  procurement  to  separation. 

(5)  Separation.  Separation  is  considered  to  be  any  form  of  termina- 
tion of  service  either  voluntary  or  involuntary,  and  includes  the  following 
deaths,  retirement,  end-of-tour  separations,  and  reduction-in-force  (RIF) 
separations.  This  function  is  closely  related  to  procurement  since  suit- 
able replacements  must  be  found  to  fill  vacancies  in  the  force.  It  also 
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affects  the  other  functions  because  of  the  personnel  changes  that  are 
required  and  the  resulting  personnel  status  changes  that  must  be  made. 

Figure  IS  shows  a breakdown  of  this  function.  Air  Force  employees 
I are  terminated  in  several  ways,  some  voluntary  and  others  involuntary. 

Voluntary  separation  dates  are  maintained  and  updated  to  reflect  the  Air 
Force  member's  duty  commitment  based  upon  his  service  entry  date  and  special 
training  received  through  the  Air  Force.  Involuntary  separations  require 
an  evaluation  and/or  review  to  determine  if  the  individual  shou  d be 
retained  in  the  Air  Force.  This  requires  that  a substantial  amount  of 
personal  and  performance  history  information  be  maintained  in  the  personnel 
system  to  identify  the  people  who  will  be  separated. 

The  two  remaining  sub-functions  in  Figure  15  are  concerned  with  (1) 
monitoring  and  tracking  separated  personnel,  and  (2)  providing  assistance 
and  support  to  separated  personnel  during  and  after  their  separation. 

Embedded  within  this  function  is  the  responsibility  for  insuring  that  the 
rights,  privileges,  and  benefits  of  retired/separated  personnel  are 
protected.  In  addition,  there  is  a responsibility  for  assisting  and 
supporting  the  next-of-kin  for  deaths,  and  for  persons  who  have  been  captured 
or  are  missing-in-action.  A separation  history  file  is  maintained  to 
monitor  the  status  and  location  of  separated  persons.  This  file  also 
contains  their  military  background  and,  if  necessary,  is  used  to  select 
and  recruit  former  Air  Force  members  to  augment  the  current  force.  In 
addition,  casualty  data  is  maintained  in  history  files  that  are  used  to 
develop  casualty  statistics  and  to  help  next-of-kin  obtain  benefits  they 
deserve.  Separation  is  the  last  function  of  the  five  primary  functions  of 
personnel  management.. 

This  was  a view  of  personnel  management  in  the  Air  Force  with  a top- 
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down  perspective.  Because  of  the  limited  documentation  available  and  the 
distance  between  the  AFMPC  and  the  author,  this  picture  may  be  incomplete 
or  may  contain  some  misconceptions.  This  picture  should  be  verified  with 
the  functional  managers  to  establish  its  credibility  and  to  determine  its 
completeness.  In  any  case,  it  is  a veiw  that  can  be  updated  and  expanded 
as  needed  to  meet  the  objectives  of  future  studies.  The  best  means  of 
improving  this  picture  would  be  (1)  to  let  the  functional  users  review 
and  critique  this  description  and  (2)  to  study  the  different  directives 
utilized  by  the  functional  users.  In  addition  to  the  functional  require- 
ments described  in  the  preceding  paragraphs,  the  following  basic  system 
requirements  are  important  design  considerations  for  any  AFMPC  data  manage- 
ment system. 

Basic  Svstem  Requirements 

The  following  basic  system  requirements  describe  the  desired  charac- 
teristics and  the  design  limitations  for  an  AFMPC  data  management  system. 
They  are  the  basic  criteria  that  are  used  to  study  system  performance  and 
to  analyze  the  feasibility  of  utilizing  a particular  system.  The  first 
requirement  to  be  discussed  is  that  the  system  be  adaptable  to  change. 

Adaptabl e to  Change ■ Any  data  management  system  at  the  AFMPC  must  be 
adaptable  to  changes.  The  very  nature  of  personnel  management  and  personnel 
policy  in  the  Air  Force  make  it  essential  that  the  data  management  system 
be  sensitive  and  responsive  to  changes  in  the  following: 

1.  National  policy 

2.  Higher  headquarters  directives 

3.  Personnel  management  philosophy 

4.  Individual  characteristics 

5.  Computer  system  characteristics 
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Currently,  there  are  nearly  three  million  transactions  each  month  that 
are  used  to  update  the  personnel  data  on  the  MPFs,  and  estimates  from  the 
system  survey  (Reference  14)  indicate  that  there  are  more  than  2500  soft- 
ware changes  to  the  personnel  data  management  system  each  year.  Many  of 
these  changes  are  directly  related  to  the  items  above,  and  in  many 
instances,  must  be  reflected  quickly  and  with  a minimum  of  effort.  This 
is  one  of  the  primary  reasons  that  the  ATMPC  uses  the  Decision  Logic  Tables 
(DLTs)  in  the  General  Update  System  (GUS) . Adaptability  to  change  has 
been  and  will  continue  to  be  a key  requirement  for  any  date,  management 
system  at  the  AFMPC. 

System  Response . People  who  use  the  personnel  data  management  system 
either  directly  or  indirectly  are  users  and  they  do  have  a response  require- 
ment that  must  be  supported  by  the  system.  It  has  been  impossible  to 
identify  or  precisely  determine  the  response  requirements  for  all  of  the 
users.  However,  the  Air  Force  recruiters  expect  a 15  second  response  on 
queries  through  the  PROMIS  system  and  the  majority  of  the  other  remote 
users  expect  a similar  response  time  on  queries.  Batch  users  axe  generally 
satisfied  with  turnarounds  varying  from  one  hour  to  one  day.  The  system 
response  times  will  have  to  be  more  clearly  defined  as  the  data  base 
system  development  proceeds. 

Quantity  and  Size.  The  back-end  data  base  processor  (s)  must  handle 
the  data  base  management  functions  of  the  MPFs  identified  in  a preceding 
section.  There  are  more  than  7 billion  charactcrs/bytes  of  information  in 
the  MPFs  identified  in  Table  III.  If  the  AFMPC  decides  to  include  any 
other  data  in  the  data  base  to  be  handled  by  the  back-end  processor (s) , 
the  quantity  of  data  managed  could  easily  exceed  10  billion  characters/ 
bytes.  Back-end  configurations  that  utilize  a data  base  computer  (DBC) 


and  are  capable  of  managing  quantities  of  data  in  the  1 to  10  billion 
byte  range  are  discussed  in  References  18,  19,  and  20. 

Another  area  of  importance  is  the  record  size  which  in  most  MPF 
files  exceeds  1000  characters/bytes.  The  Civilian  MPF  contains  records 
that  are  more  than  9600  characters/bytes  long.  These  large  records  could 
require  that  a large  amount  of  data  be  transferred  between  the  host  and 
the  back-end (s)  for  each  transaction. 

There  is  little  doubt  that  the  communication  link(s)  between  the  host 
and  the  back-end (s)  will  have  to  be  capable  of  handling  large  volumes  of 
data  because  of  the  large  record  sizes  and  the  large  number  of  transactions 
that  are  processed  against  the  MPFs.  However,  the  volume  of  data  that  is 
passed  between  the  computers  must  be  kept  to  a minimum  consistent  with 
data  base  and  personnel  management  requirements.  F.fficient  methods  of  data 
transfer  must  be  investigated  and  utilized  to  reduce  and/or  minimize 
system  response  time  if  feasible. 

Data  Pasj?  Structure . The  data  base  structure  should  be  efficient  for 
botli  update  and  retrieval  to  maximize  the  efficiency  of  the  system.  More 
than  70  per  cent  of  the  CPU  time  is  devoted  to  supporting  these  two  functions 
in  the  current  system.  The  current  data  base  strucure  is  basically  a 
collection  of  independent  files  that  contain  a significant  amount  of 
duplicated  information.  In  addition,  the  files  have  an  "index  random" 
structure,  which  means  that  the  files  are  managed  by  using  a sequential 
key  to  access  records  that  are  stored  randomly.  The  key  for  personnel  files 
is  the  SSAN  of  the  individual  and  this  is  not  the  most  practical  key  to  use 
for  personnel  management.  The  SSAN’  is  unique,  and  it  is  used  by  other 
agencies  like  the  Internal  Revenue  Service,  Social  Security  Administration, 
and  the  Air  Force  Accounting  and  Finance  Center;  however,  it  is  not 
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descriptive  of  the  person  or  his  skills. 

There  are  meaningful  keys  that  could  be  used  or  developed  for  use. 

For  example,  a descriptive  key  similar  to  a "fingerprint"  would  be  more 
efficient  and  useful  for  file  management.  This  "fingerprint"  should  be 
an  identifier  that  describes  the  individual,  his  background,  and  his 
capabilities.  Certain  personal  characteristics  are  basic  and  are  fixed 
very  early  in  a person's  life  and  career.  For  example  the  following: 

1.  Date  of  birth 

2.  Place  of  birth 

3 . Name 

4.  Race 

5.  Date  employed  by  or  entered  the  Air  Force 

6.  Date  graduated  from  high  school 

7.  Source  of  commission 

8.  Date  of  commission 

Other  items  provide  a historical  picture  of  the  person  and  become  fixed 
once  they  occur,  for  example: 

1.  Academic,  military,  and  technical  training 

2.  Promotions 

3.  Assignments 

4.  Duties  and  skill  levels 

If  a key  were  developed  from  items  similar  to  those  in  the  lists  above,  the 
key  would  change  very  little  avid  would  be  descriptive  of  the  individual.  If 
the  remaining  personnel  data  were  clustered  around  or  linked  to  the  key,  the 
data  base  updates  and  retrievals  would  be  more  efficient  and  less  time 
consuming. 

New  concepts,  along  with  traditional  data  base  structures  shou'd  be 


evaluated  to  find  the  most  effective  and  efficient  way  to  structure  the 
AFMPC  data  base.  Some  of  the  data  base  design  concepts  and  data  structures 
discussed  in  References  17,  25,  and  26  might  be  very  helpful  in  developing 
an  efficient  data  base  structure  for  the  back-end  system. 

Security.  The  data  base  must  be  secure  and  protected  from  unauthorized 
access  for  both  security  and  reliability  considerations;  consequently,  the 
security  and  access  restrictions  must  be  clearly  defined,  understood,  and 
incorporated  in  the  design  of  the  data  management  system.  Currently,  there 
is  classified  information  stored  in  the  Manpower  MPF  and  the  Personnel 
Accounting  Symbol  (PAS)  file.  In  addition,  selected  data  in  many  of  the 
other  personnel  files  is  sensitive  and  must  be  protected  due  to  Privacy 
Act  restrictions  and  other  considerations.  For  example,  the  General  Officer 
System  (GO S)  file  is  maintained  and  updated  at  the  AFMPC,  but  the  informa- 
tion is  only  reviewed  in  Washington,  DC.  Transactions  relating  to  the 
release  of  privacy  information  are  recorded  in  the  Privacy  Act  Tracking 
System  (PATS)  file,  which  is  used  to  monitor  the  dissemination  of  privacy 
information  outside  of  the  personnel  system.  When  a person  separates  from 
the  Air  Force,  the  data  on  the  PATS  file  related  to  his  privacy  information 
is  transferred  to  a PATS  history  file  for  reference  if  necessary. 

Cost . The  method  used  to  overcome  the  AFMPC  system  workload  and 
associated  data  management  update  and  retrieval  problems  must  be  cost 
effective  relative  to  suitable  alternatives.  There  are  several  possible 
solutions  which  include  (1)  buying  or  leasing  a larger  machine,  (2) 
restructuring  the  data  base  and  using  the  existing  hardware,  and  (3) 
utilizing  a back-end  data  base  processor  system  configuration  with  an 
efficient  data  base  structure.  The  purchase  of  a larger  machine  or  a 
back-end  processor  will  require  a special  procurement  effort  and  will  incur 
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some  additional  training,  installation,  and  maintenance  costs.  Many  other 
cost  factors  must  also  be  considered  before  a final  decision  is  made  to 
utilize  a back-end  system  configuration  or  to  select  seme  other  alternative 
solution. 

The  functional  requirements  and  the  basic  system  requirements  will 
determine  whether  a new  or  different  system  conf iguration  is  needed.  First 
however,  a plan-of-attack  is  required  to  focus  the  large  effort  that  is 
required  to  evaluate  the  feasibility  of  using  a different  system  configurat 
A plan  that  describes  the  steps  required  to  complete  a comprehensive  evalu- 
ation of  a back-end  data  base  processor  at  the  AFMPC  is  presented  in  the 
next  chapter.  This  discussion  is  followed  by  an  analysis  of  the  feasibilit 
of  using  a back-end  system  at  the  AFMPC  considering  the  general  require- 
ments described  in  this  chapter. 


I 


V Results  of  this  Study 


General 

This  chapter  describes  the  effort  involved  in  this  thesis  and 
provides  a plan-o C-attack  that  will  end  with  the  evaluation  of  a back-eui 
data  base  processor  system  for  the  AFMPC.  This  plan-of-attack  is  designed 
to  look  at  the  system  with  a ^op-down  perspective.  This  means  that  the 
system  requirements  will  be  completely  redefined  and  documented  based  upon 
the  current  charter  and  personnel  management  responsibilities  of  the  AFMPC. 
Following  the  description  of  the  plan-of-attack,  there  is  a discussion  of 
the  feasibility  of  using  a back-end  data  base  processor  system  at  the  AFMPC. 

The  back-end  concept  is  discussed  considering  the  general  system  require- 
ments and  other  information  presented  in  the  preceding  chapters.  The  following 
paragraphs  describe  the  effort  involved  in  developing  this  thesis. 

The  Effort . The  initial  goal  of  this  thesis  was  to  develop  the  func- 
tional data  requirements  necessary  to  implement  a back-end  data  base  pro- 
cessor at  the  AFMPC  by  using  "Structured  Analysis”  (SA) • The  available 
literature  was  studied  to  become  familiar  with  both  the  Air  Force  personnel 
system  and  the  back-end  processor  concept.  This  knowledge  was  augmented 
with  information  obtained  on  three  different  visits  to  the  AFMrc  at 
Randolph  AFB,  Texas.  A total  of  11  days  was  spent  on-site  gathering 
information  about  the  system  and  its  general  requirements.  This  involved 
approximately  80  hours  spent  in  interviews,  briefings,  and  discussions  plus 
20  hours  devoted  to  obtaining  the  reports  and  other  documentation  required 
to  develop  a comprehensive  understanding  of  the  current  system.  The 
discussions,  interviews,  and  briefings  involved  over  30  different  people; 

f including  systems  planners,  programmers,  operations  managers,  requirements 
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analysis,  operations  schedulers,  and  a few  functional  managers. 

The  goal  of  the  study  was  revised  because  of  the  knowledge  and  under- 
standing of  the  system  that  was  obtained  during  these  visits.  It  became 
evident  that  a solid  background  and  perspective  o?  the  overall  system  and 
the  problem  should  be  developed  and  documented . Thi . documentation  -.ill 
allow  other  people  to  complete  follow-on  studies  with  a minimum  of  effort. 

The  perspective  of  this  thesis  was  raised  and  the  goal  was  revised  because 
of  the  . 'ed  to  (1)  document  the  system  and  its  environment,  (2)  define  the 
problem,  and  (5)  establish  a direction  for  future  studies.  The  investigation 
was  refocused  and  generally  confined  to  analyzing  and  documenting  the 
current  system.  As  a result  of  the  investigation,  course  of  action  \ un- 
developed that  will  satisfy  the  original  request  of  the  Ai-'MPC.  7h ; s 'ourae 
of  action  fpl an-of-attack)  is  presented  later  in  the  chapter,  and  it  will 
provide  a focus  and  direction  for  future  studies. 

The  preceding  chapters  art  a result  of  the  changed  perspective  and 
the  goal  of  this  thesis  and  represent  a significant  port  of  this  investi- 
gation. A brief  analysis  of  the  current  system  is  provided  in  the  following 
paragraphs  and  is  followed  by  the  plrn-of -attack.  The  plan-of-attack  is 
based  upon  a top-down  approach  to  problem  solving  and  emphasizes  require- 
ments definition.  The  following  system  analysis  highlights  the  system 
problems  and  points  out  several  factors  that  contribute  to  these  problems. 

Analysis  of  Current  System.  This  analysis  is  a summary  of  facts 
related  to  system  problems  and  re-'lects  information  presented  in  preceding 
chapters.  The  AFMPC  data  management  system  is  nearly  saturated  with  the 
CPU  utilization  at  or  above  90  per  cent  continually.  An  extremely  large 
portion  of  the  CPU  workload  is  concerned  with  either  MPF  data  updates  or 
MFP  data  retrievals.  More  than  50  per  cent  of  the  CPU  time  is  devoted  to 
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MPF  data  retrievals  and  approximately  20  per  cent  of  the  CPU  time  is 
devoted  to  updates.  The  time  between  updates  on  the  different  MPF  files 
varies  from  two  days  to  one  week  because  of  the  heavy  workload.  The 
"ripple"  effect  caused  by  the  file  inter-relationships  and  the  update 
schedule  may  cause  several  days  or  weeks  to  elapse  before  the  final  impact 
of  a change  is  reflected  in  all  files. 

Several  factors  contribute  to  the  CPU  workload  problem  and  the  file 
update  problem.  First,  the  MPFs  are  either  keyed  upon  Social  Security  Number 
(SSAN)  or  job  number,  and  this  makes  the  file  structures  efficient  for  updates 
but  inefficient  for  retrieval.  Second,  there  are  more  than  200  files  in  the 
total  personnel  system  at  the  AFMPC,  and  many  of  these  files  contain  data 
elements  that  are  duplicated  in  one  or  more  of  the  MPFs.  This  means  that 
many  redundant  updates  are  required  to  update  files  that  contain  duplicated 
data.  Third,  there  are  more  tiian  250  different  Interface  links  between 
the  MPFs  and  the  other  files.  This  is  indicative  of  (1)  the  amount  of 
data  that  is  duplicated  in  the  different  files.,  and  (2)  the  complexity  of 
the  data  relationships  between  the  MPFs  and  the  other  files.  These  complex 
relationships  are  the  primary  reason  it  takes  so  long  for  a change  to  be 
fully  reflected  in  all  of  the  files.  Finally,  the  current  system  does  not 
reflect  a top-down  design  and  does  not  have  an  efficient  structure  for  data 
management.  A system  that  is  designed  top-down  tends  to  be  (1)  easier  to 
understand  and  maintain,  (2)  more  efficiently  structured  to  satisfy  the  system 
requirements,  and  (3)  more  easily  redesigned  and  modified.  The  current  data 
management  system  was  developed  by  centralizing  management  functions  and 
adding  files  and  data  requirements  to  the  existing  system.  This  development 
process  has  caused  data  to  be  duplicated  throughout  the  file  system  and  in- 
creased the  complexity  of  data  relationships  between  tne  files.  This  has 
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adversely  affected  the  system  workload  and  data  management  at  the  AFMPC. 

The  following  plan-of-attaek  provides  a top-down  approach  to  solve  the 
problems  and  eliminate  the  deficiencies  described  in  the  preceding  para- 
graph. The  first  two  phases  in  the  plan-of-attack  outline  the  general  steps 
required  to  support  investigations  into  different  possible  solutions  to 
the  data  base  problem.  Phases  3 and  4 arc  slanted  toward  the  back-end  data 
base  processor  concept  and  its  implementation  at  the  AF.VPC.  However, 
alternate  solutions  may  be  more  promising  as  follow-on  studies  are  developed 
and  may  be  investigated  using  the  information  obtained  in  the  first  two 
phases . 

Plan- of -At tack 

There  are  many  actions  that  must  be  completed  to  properly  satisfy  the 
request  by  the  AFMPC  to  evaluate  and  model  a back-end  data  base  processor. 
These  actions  and  activities  are  divided  into  four  different  phases,  which 
are  (1)  Analyze  the  Problem  and  Define  the  General  Requirements,  (2)  Define 
the  Detailed  Requirements  of  the  System,  (3)  Develop  a Back-end  Configuration 
and  Document  the  System  Interface,  and  (4)  Model  and  Evaluate  the  Back-end 
System. 

Analyze  the  ProbI em  and  Define  the  General  Requirements.  This  is  an 
essential  part  of  the  overall  study  because  it  provides  the  focus  and  the 
foundation  for  the  follow-on  studies.  This  thesis  serves  that  purpose  for 
the  back-end  data  base  processor  evaluation.  It  also  establishes  an 
environment  where  realistic  alternatives  can  be  evaluated  with  very  little 
duplicated  effort.  The  preceding  sections  of  this  thesis  have  established 
the  background  and  focused  the  problem  for  future  studies.  The  general 
requirements  were  discussed  in  Chapter  IV  and  provide  a starting  point  for 
the  next  phase  of  study. 
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The  detailed  requirements  of  the  system 


Define  Detailed  Requirements, 
must  be  known  and  understood  before  a realistic  model  of  a back-end 
processor  system  can  be  developed.  This  is  a broad  area  and  involves  many 
different  aspects  of  the  system  which  must  be  described  either  by  or  for 
the  AFMPC.  These  requirements  must  be  explicitly  and  accurately  documented 
in  order  to  develop  system  configurations  that  will  meet  and  satisfy  the 
AFMPC  data  management  requirements*.  The  detailed  requirements  are  divided 
into  two  categories;  (1)  detailed  functional  requirements,  and  (2)  detailed 
system  requirements. 

These  categories  are  similar  to  the  requirements  categories  addressed 
in 'Chapter  IV.  However,  during  this  phase  of  the  overall  study,  the 
requirements  must  be  defined  in  more  depth.  The  detailed  functional 
requirements  are  discussed  first  and  are  followed  by  a discussion  of  the 
detailed  system  requirements. 

(1)  Detailed  Functional  Requirements.  In  concert  with  previous 
discussions,  the  AFMPC  personnel  management  functions  and  responsibilities 
are  defined  as  the  "functional  requirements"  of  the  system.  The  functional 
requirements  in  Chapter  IV  can  be  used  as  a starting  point  but  they  must 
be  validated,  expanded,  and  documented  in  much  greater  detail.  In  addition, 
the  data  interactions  caused  by  personnel  management  actions,  functions,  and 
activities  must  be  well-defined,  understood  and  documented.  The  detailed 
functional  requirements  and  the  associated  data  interactions  should  be 
developed  by  looking  at  the  functional,  personnel  management  responsibilities 
of  the  AFMPC  with  a top-down  perspective.  A top-down  perspective  will  help 
create  an  integrated,  cohesive,  and  complete  picture  of  the  AFMPC  fata 
management  system.  It  may  be  necessary  to  document  the  functional  require- 
ments from  different  points-of-view  to  completely  reflect,  the  system 
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requirements;  i.e.  (1)  the  user,  (2)  the  manager,  and  (3)  the  designer. 

The  functional  requirements  of  the  current  system  are  not  well-defined 
or  readily  available.  In  addition,  they  have  not  been  documented  from  a 
top-down  perspective.  This  makes  it  difficult,  if  not  impossible,  to  under- 
stand the  inter-relationships  and  functional  significance  of  the  data  in  the 
AFMPC  data  base  system.  Currently,  a large  amount  of  data  is  maintained 
in  the  data  management  system  for  each  person  and/or  job  in  the  Air  force. 
For  instance,  the  majority  of  the  records  in  the  MPFs  are  more  than  1000 
characters  long.  This  data  is  usually  maintained  in  the  data  base  system 
t.o  support  specific  personnel  management  functions.  However,  some 
individuals  at  the  AFMPC  question  whether  all  of  this  data  is  actually 
needed  or  utilized.  The  files  and  data  should  be  scrutinized  and  the  data 
should  be  deleted  from  the  system  if  it  is  no  longer  functionally  signifi- 
cant or  needed. 

The  functional  requirements  documentation  should  include  the  inter- 
relationships of  the  data  in  the  files,  t lie  cluster  (closeness)  relation- 
ships of  the  data,  and  the  relative  import a ire  of  the  data  to  the  personnel 
management  functions.  Everest  et  al  (Ref  23:  7-5  y)  describes  data 
characteristics  and  data  relationships,  and  disc  i c how  th  s information 
is  used  to  specify  requirements  and  structure  a data  management  system. 

A detailed  understanding  of  data  requirements  and  data  relationships  is 
needed  to  develop  an  efficient  data  base  structure  and  system  for  the  back- 
end data  base  processor.  The  more  efficient  the  data  structure,  the  more 
efficient  the  system  will  be. 

The  functional  requirements  should  be  identified  and  then  correlated 
with  the  known  inter-relationships  in  the  current  system  to  insure  that 
the  true  requirements  arc  properly  identified.  Early  in  the  requirements 


63 


definition  process,  a "user's  manual"  should  be  developed  that  defines 
the  user-machine  interface.  This  "user's  manual"  is  a valuable  source 
of  information  for  structured  approaches  to  requirements  definition.  Formal 
structured  methods  should  be  used  to  develop  and  document  these  require- 
ments so  that  a complete  and  accurate  definition  of  requirements  is  produced 
Structured  Analysis  (SA)  and/or  Computer  Aided  Design  and  Systems  Analysis 
Tool  (CADS AT) , formerly  Computer  Aided  Requirements  Analysis  (CARA) , are 
tools  that  c-n  be  very  useful  during  requirements  studies  (Ref  5,  6,  and 
27).  The  following  sources  should  be  helpful  in  gathering  the  information 
to  define  the  functional  requirements: 

(1)  "Reports"  file  (Ref  2S) 

(2)  "Rich"  file  (Ref  27) 

(3)  "GUSDATA"  cross  reference  retrieval  (Ref  30) 

(4)  "Working  Group  Survey"  forms  (Ref  14) 

(5)  USAFPP  (Ref  7) 

(6)  Air  Force/AFMPC  Manuals  and  Regulations  (Ref  10  - 13) 

(7)  Functional  users 

(8)  Personnel  programmers 

Most  of  the  source  information  will  have  to  come  from  Air  Force  publication- 
the  functional  users  and  managers,  and  the  supporting  programmers.  After 
the  detailed  functional  requirements  have  been  identified  and  documented, 
the  detailed  system  requirements  can  be  fully  developed  and  specified. 

(2)  Detailed  System  Requirement. s . The  detailed  system  requirements 
must  be  clearly  defined  and  documented,  too.  The  system  requirements,  as 
discussed  in  Chapter  IV,  are  derived  from  the  functional  requirements, 
desired  performance  characteristics,  and/or  the  known  design  limitations. 

In  addition,  the  specific  evaluation  and  system  design  criteria  to  be  used 
in  developing  and  analyzing  a back-end  data  base  processor  system  must  be 
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explicitly  defined  and  stated  by  or  for  the  AFMPC.  The  following  list 
of  items  includes  the  most  important  system  requirements  and  performance 
considerations  that  must  be  defined: 

(1)  Content  of  the  data  base  files 

(2)  Response  time  requirements  for 

(a)  Functional  users 

(b)  Programmers 

(c)  Batch  users 

(d)  Remote  terminal  users 

(e)  Others 

(3)  Flexibility  and  adaptability  to  change 

(a)  Criteria  to  describe  types  and  number  of  changes 

(b)  Speed  of  adaptability 

(4)  Special  preferences  or  needs  in  system 

(5)  Cost  considerations 

(6j  Requirements  to  expand  capacity 

(7)  Physical  facility  - space,  location,  power,  etc. 

(a)  Capabilities 

(b)  Restrictions 

(8)  Projected  workload  pertaining  to  jobs  and  transactions 

(a)  Jobs  - types,  quantity,  and  sizes 

(b)  Transactions  - types , quantity,  and  relative 

frequency  of  use 

(c)  Workload  trends  - highs,  lows,  and  means 

(d)  Future  trends  in  workload 

Items  may  be  added  to  or  deleted  from  this  list  to  meet  the  objectives  of 
future  studies  and  satisfy  the  requirements  of  the  AFMPC.  The  information 
in  this  list  is  needed  to  complete  the  last  two  phases  of  the  overall 
study  requested  by  the  AFMPC.  Any  person  who  attempts  to  define  the 
detailed  system  requirements  should  have  some  knowledge  and  understanding 
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of  (1)  requirement  definition  tools  and  techniques,  and  (2)  computer 
performance  evaluation  (CPE)  principles  and  techniques. 


Develop  a ! : C.  ; i f'onr : . ur  ;V  (on  i,id  Document  the  Interface.  This 
step  in  the  study  is  required  to  fully  understand  the  design  alternatives 
and  comprehend  the  interface  requirements.  Prior  to  accomplishing  this 
step  in  the  back-end  model  development  process,  a system  designer  must 
understand  the  system  requirements  identified  in  the  preceding  section,  and 
specified  by  the  AFMPC.  After  the  back-end  system  configuration  is  developed, 
the  interface  requirements  must  be  defined  and  documented.  Embedded  within 
the  activities  of  this  pahse  is  the  requirement  to  define  a data  base 
structure.  This  is  necessary  because  the  data  base  structure  could  affect 
the  interface  requirements  of  the  system.  The  following  list  identifies 
items  that  should  be  included  in  the  interface  documentation: 

(1)  Hardware 

(a)  Type  of  hardware  (microprocessors,  minicomputers, 
or  large  data  base  computer) 

(b)  Compatibility  with  current  and  future  systems 

(c)  Physical  requirements  (space,  location,  power,  etc.) 

(d)  Storage  mediums  and  memory  units 

(2)  Software 

(a)  Conversion  packages/languages  for  the  host(s) 
and  the  back-end  (s) 

(b)  Communications  protocols  (encoding,  encryption, 
decoding,  decryption,  transmission,  reception,  etc.) 

(c)  Data  base  languages  and  software 

(d)  Host  languages  and  software 

(3)  Data  requirements  and  data  base  design 
Transfer  rates  (volume) 

Transfer  quantity  per  transaction  (record  sice) 

Data  protection 


(a) 

(b) 
(=) 
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(d)  Storage  devices  for  data  base  (types,  capacity, 
and  cliaracteristics) 

(e)  File  organization,  data  structures,  and  access 
techniques 

This  list  may  not  be  complete  but  it  does  provide  an  outline  of  items  to 
consider  during  the  documentation  of  the  interface  requirements  for  a 
back-end  data  processor  system  at  the  AFMPC.  Items  may  be  added  to  or 
deleted  from  this  list,  as  necessary,  to  meet  the  objectives  of  future 
studies  and  satisfy  the  requirements  of  the  AFMPC.  During  this  phase,  some 
design  and  configuration  decisions  will  be  required  to  restrict  and  bound 
the  scope  of  the  study  or  it  will  expand  rapidly  and  could  quickly  become 
unmanageable.  A person  who  continues  the  study  in  this  particular  area 
should  have  some  knowledge  of  data  base  design  and  management,  data 
structuring  approaches,  security  methods,  communications  protocols,  and 
data  storage  systems.  There  are  many  papers,  journal  articles,  and/or 
texts  available  that  discuss  these  subjects  in  detail  (Ref  17,  21,  22,  .77, 
and  26) . 

Model  and  Evaluate.  This  is  the  final  step  in  analyzing  the  feasi- 
bility of  utilizing  a back-end  data  base  processor  at  the  AFMPC.  After  xhe 
system  requirements  have  been  identified  and  the  basic  system  configuration 
with  its  associated  interface  requirements  has  been  designed,  the  models  can 
be  developed  to  analyze  and  evaluate  the  system  and  its  capabilities.  The 
nature  and  types  of  models  utilized  will  depend,  in  large  measure,  upon 
the  results  obtained  in  preceding  phases.  The  models  will  be  based  upon 
the  functional  and  performance  requirements  identified  during  the  first  phase 
and  the  system  configuration (s)  developed  in  the  second  phase.  The  key 
considerations  will  be  the  effect  of  the  back-end  on  response  time  and  the 
overall  system  workload.  The  analysis  and  the  evaluation  of  the  system 
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model:,  will  be  based  upon  criteria  and  standards  established  during  the 
second  phase. 

A person  who  works  on  this  phase  should  have  a knowledge  of  computer 
performance  evaluation  CCPF)  tools  and  techniques,  the  engineering  aspects 
of  probability  and  statistics,  and  computer  simulation  and  modeling 
techniques.  This  discussion  has  been  kept  very  general,  since  the  modeling 
approach  must  be  determined  by  the  person (s)  developing  the  model  in 
consonance  with  the  AFMPC  requirements. 

The  preceding  discussions  in  this  chapter  outline  a course  of  action 
that  will  culminate  in  the  development  and  evaluation  of  a model  of  a 
back-end  data  base  system  configuration  for  the  AFMPC.  In  the  following 
section,  possible  back-end  system  configurations  are  analyzed  and  the 
feasibility  of  utilizing  a back-end  system  is  discussed. 

A Baek-Knd_  I ata  Base  Processor  at  the  AFMPC 

This  section  contains  a discussion  of  different  possible  back-end 
system  configurations  and  their  application  at  the  AFMPC.  This  is  followed 
by  discussion  of  the  feasibility  of  utilizing  a back-end  system  configura- 
tion based  upon  the  general  system  requirements  and  the  capabilities  of 
back-end  processors. 

System  Configuration . A single  host  - single  back-end  configuration 
is  the  simplest  back-end  system  that  can  be  designed,  and  it  has  the 
simplest  interface.  There  is  only  one  source  for  commands  to  the  back-end, 
and  since  only  a single  host  needs  to  be  served,  the  status  of  the  data 
base  can  be  controlled  relatively  easily.  Security  measures  are  also 
simpler  to  implement  because  of  the  single  interface.  The  size  of  the 
AFMPC  data  base,  the  two  existing  host  computers  at  the  AFMPC,  and  the 
mission  of  the  AFMPC  may  make  this  particular  configuration  impractical. 
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A multiple  host  - single  back-end  will  require  that  the  data  base  status 
be  maintained  to  provide  some  means  of  controlling  the  condition  cf  the 
data  in  the  data  base.  The  read-write  status  of  the  data  base  files  roust 
be  maintained  or  a request  through  one  host  could  retrieve  data  that  is  in 
the  process  o'  being  updated  by  the  other  host.  Control  of  data  updates 
and  retrieval  must' be  maintained  and  utilised  to  insure  chat  the  information 
obtained  from  this  data  is  meaningful  and  consistent.  The  multiple  host  - 
single  back-end  is  realistic  configuration  for  the  AFMPC  since  there  are 
two  host  computers  currently.  This  is  contingent  upon  the  fact  that  a 
single  back-end  could  handle  the  data  management  functions  required  to 
support  personnel  activities. 

The  single  host  - multiple  back-end  configuration  is  possible  but  not 
likely  since-  the  AFMPC  has  the  two  host  computers.  The  interface  in 
this  configuration  is  more  complex  than  the  first  configuration  discussed, 
since  it  also  requires  controls  and  monitors  to  keep  track  of  file  status. 

An  advantage  of  this  system  is  that  several  independent  file  systems  could 
be  processed  concurrently.  This  type  configuration  might  permit  the  use 
of  several  smaller  processors  which  might  he  less  expensive  than  a sir,f.le 
larger  system.  It  docs  provide  some  degree  of  redundancy  and  flexibility 
in  system  design  and  operation. 

The  multiple  host  - multiple  back-end  configuration  has  an  extremely 
complex  interface  because  of  the  number  of  different  processors  involved. 
This  configuration  also  requires  that  some  form  of  file  status  be  main- 
tained and  utilized.  The  security  problem  is  com.pounded,  and  the  commun- 
ications protocol  is  more  critical  due  to  the  number  of  different  units 
involved  in  the  system.  This  configuration  is  basically  a distributed 
processing/data  base  network  and  can  possibly  distribute  and/or  minimize 
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the  workload  of  the  hosts  nnd/or  the  back-end  processors.  Any  system  that 
is  configured  with  a back-end  processor  has  the  basic  elements  required  to 
either  join  or  be  developed  into  a distributed  network  regardless  of  the 
system's  original  back-end  configuration.  The  complexity  of  the  multiple 
host  - multiple  back-end  configuration  will  probably  preclude  the  use  of 
it  at  the  AFMPC,  at  least  initially.  !!  ••..ever,  the  Alh IPC  with  two  hosts 
plus  the  base  level  systems  could  be  developed  into  a network  system  if 
it  proves  to  be  desirable  in  the  futur  . 

The  different  possible  back-end  y - : . . configurations  and  their 
application  at  the  AFMPC  have  been  dis-  jssed  briefly.  The  fol lowing 
discussion  is  devoted  to  analysing  the  feasibility  of  utilising  a back-end 
system  at  the  AFMPC. 

FeasibiJity  of  a Pack-end  Conf igurat ion.  The  following  analysis  and 
comments  are  presented  based  upon  a comparison  of  the  general  requirements 
discussed  in  Chapter  IV  and  the  capabilities  of  back-end  data  base 
processors.  There  are  back-end  designs  that  are  capable  of  handling  the 
large  quantity  of  data  required  to  support  personnel  management.  The 
security  requirements  at  the  AFMPC  are  significant  but  a single  back-end 
system  configuration  will  allow  the  security  functions  to  be  concentrated 
at  a single  point.  The  large  amount  of  CPU  time  that  is  dieted  to 
updating  and  retrieving  data  from  the  MPFs  would  be  transferred  to  the 
back-end.  However,  some  processing  overhead  would  be  required  to  handle 
the  transfers  to  and  from  the  back-end,  but  the  overall  workload  on  the 
host  system  would  be  reduced  significantly.  In  fact,  it  is  conceivable  that 
the  workload  on  the  host(s)  v/ould  be  reduced  enough  so  that  the  entire  host 
workload  could  be  handled  by  one  B-6700  host  machine. 

If  a specialized  data  base  computer  (DB( ) is  utilized  and  an  efficient 
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data  base  structure  is  used,  the  response  times  would  probably  decrea 
or  remain  comparable  to  the  response  times  of  the  current  system.  A hu 
end  data  base  processor  has  improved  response  times  by  one  or  two  or.-  -r: 
of  magnitude  for  complex  data  management  tasks  such  as  storing  a record  th..t 
is  a member  of  a number  of  sorted  sets  (Ref  16‘6  - 43/582).  The  comr.'.  m- 
tions  interface  and  its  effect  on  response  time  is  difficult  to  deter  ' 
since  the  delays  caused  by  queuing  in  both  the  host  and  the  back-cud  are 
unpredictable  at  this  point.  The  time  involved  in  data  transfer  an.!  r ponses 
in  Reference  16  was  less  than  three  seconds  which  could  lure  been  reduced  to 
less  than  one  second  by  increasing  the  capacity  of  the  communications  Id., 
to  5 OK  BAUD.  The  back-end  processor  is  quite  appealing,  since  it  provides 
a great  deal  of  flexibility  for  the  future  and  appears  to  meet  the  ament 
system  requirements.  This  is  especially  true  if  current  and  projected 
advances  in  hardware  technology  are  considered. 

Another  possible  alternative,  not  mentioned  previously,  is  to  structure 
the  data  base  and  utilize  one  of  the  B-6700s  as  a back-end  processor  and 
utilize  the  other  as  the  host.  This  would  not  require  a new  computn  . .1 
could  reduce  the  costs  involved  in  converting  to  a back-end  system  cor'  i 
uration.  In  addition,  it  is  quite  probable  that  a large  computer  will  be 
required  to  handle  the  functions  of  the  back-end  processor  unless  a number 
of  smaller  computers  are  utilized.  The  B-6700  might  be  the  answer  and 
there  could  be  an  advantage  to  retaining  both  B-6700s;  for  instance, 
redundancy  or  software  compatibility. 

At  this  point  in  the  overall  investigation,  a back-end  system  does 
appear  to  be  a reasonable  solution  to  the  problems  of  CPU  utilization  and 
timely  data  base  updates  at  the  AFMPC,  for  the  following  reasons: 
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Back-end  systems 

(1)  can  handle  the  large  volume  of  data  maintained. 

(2)  are  capable  of  meeting  the  knovm  response  requirements. 

(3)  allow  security  functions  to  be  concentrated  at  a single 
point  (the  back-end  processor) . 

(4)  are  building  blocks  for  distributed  networks,  which 
improves  the  system  design  flexibility  and  adaptability 

(5)  arc  improving  rapidly  with  advances  in  computer  technology, 
especially  advances  in  hardware  and  data  base  design. 

In  this  chapter,  a course  of  action  has  been  presented  that  will  help 
the  AivlPC  develop  an  effective  and  efficient  solution  to  their  worl load  and 
data  management  problems.  In  addition,  the  potential  application  of  a 
back-end  data  base  management  system  was  discussed,  and  it  appears  to  be 
a realistic  solution  to  the  AFMPC  problems.  Some  final  comments  on  the  results 
of  this  thesis  are  presented  in  the  next  chapter. 


72 


I 


VI  Conclusion 

The  initial  request  by  the  AF.'PC  for  a model  of  a bach- end  data 
processor  rapidly  developed  into  a much  larger  problem.  Because  of  the 
magnitude  of  the  problem,  the  perspective  of  this  thesis  was  raised  and 
the  primary  effort  was  focused  upon  developing  a solid  foundation  for 
future  studies  and  outlining  a course  of  action  to  satisfy  the  original 
request . This  portion  of  the  thesis  contains  some  final  comments  about 
future  studies  in  these  areas  and  the  utility  of  "Structured  \nalysis"  (SA) 
in  a study  of  this  magnitude  and  complexity. 

(1)  The  ATMPC  should  take  action  to  identify  and  document  their  system 
requirements  using  a top-down  approach.  A "user's  manual"  must  be  dcvcU  >c  ; 
that  defines  the  user  - machine  interface  and  describes  the  functions  u . r 
must  perform  on  the  system,  since  it  is  a valuable  source  of  information 
for  structured  approaches  to  requirements  definition.  This  info  mat  ion  wi  : i 
be  necessary  for  any  system  development  and  will  enable  the  system  to  be 
maintained  and  operated  efficiently.  By  using  a top-down  approach,  the 
details  of  the  requirements  can  be  controlled  at  different  levels  consistent 
with  the  particular  needs  of  the  affected  individual.  In  addition,  the 
requirements  definition  will  then  reflect  a fully  integrated  and  cohesive 
picture  of  the  system  and  allow  the  AFMFC  to  develop  an  efficient  data  base 
structure.  Future  studies  in  this  area  will  need  the  firm  commitment  and 
’ , support  of  the  AFMPC  and  other  affected  agencies.  These  studies  will 

••  nif  leant  amount  of  time  and  effort  if  they  are  completed  in  any 

i at  of  detail . 

• end  data  base  processor  configurations  should  be  investigated 
'1.  • validity  of  this  concept  has  been  addressed  in  m *.ny 
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publications  and  is  receiving  increasing  attention  from  industry  and 
computer  vendors  (Ref  23:35).  The  potential  advantages  seem  to  outweigh 
the  disadvantages,  although  the  AF.'iPC  has  not  quantified  the  required 
performance  standards  for  such  a system.  However,  alternative  solutions 
to  the  problems  of  heavy  machine  utilisation  and  timely  data  base  file 
maintenance  nay  become  apparent  as  the  overall  study  continues,  and  there 
may  be  more  practical  solutions  than  a back-end  system. 

(3)  The  original  goal  of  this  thesis  was  t.o  "document  the  functional 
requirements  of  the  system  with  SA  models."  However,  the  level  and  the 
perspective  of  this  investigation  were  raised  and  the  goal  was  revised 
because  of  the  complexity,  size,  and  scope  of  the  AFMPC  data  maneger/ent 
system.  During  this  period  of  time,  SA  was  utilized  to  develop  a more 
complete  understanding  of  the  functional  requirements  of  the  AFIIi’C.  The 
SA  models  ch-velcpcd  by  the  author  were  not  included  in  this  thesis  because 
they  were  incomplete  and  lacked  consistency.  It  was  difficult  to  create 
satisfactory  SA  models  for  the  following  reasons:  (1)  the  distance  between 
the  AS'MPC  and  the  author,  (2)  the  complexity  and  magnitude  of  the  problem, 
(5)  the  lack  of  centralized  documentation  that  outlines  the  functional 
relationships  of  the  data  files,  (4)  the  need  for  several  models  with 
different  viewpoints,  (3)  the  lack  of  available  readers  with  a knowledge 
of  both  the  technique  and  the  personnel  environment,  and  (6)  the  time 
available  for  thesis  completion.  A discussion  with  SOFTIiCH  experts 
indicated  that  ir,  some  instances  on  projects  of  this  size,  complexity, 
and  character,  it  nay  be  helpful  tc  develop  the  data  model  first  (Ref  31). 
This  approach  was  not  attempted  because  of  the  time  limitation  and  other 
factors  listed  above.  However,  the  time  devoted  to  SA  model  development 
was  worthwhile  because  it  resulted  in  a more  complete  and  accurate  picture 
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of  the  personnel  system.  It  focused  attention  upon  some 
author's  perspective  of  the  system  which  were  eliminated 
research  and  discussions  with  personnel  at  AFMPC. 

The  preceding  comments  summarize  the  results  of  this 
study  should  be  useful  as  a stepping  stone  and  foundation 
on  studies  that  are  required.  It  was  designed  to  provide 
background  and,  also,  to  establish  a direction  and  focus 


weaknesses  in  the 
through  suppl  ei'  ent ary 

thesis.  This 
for  the  follow- 
a comprehensive 
for  future  studies. 
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i ■ it ; n (Ref  3] 


B Current  AF.'TC  Commuter  Syst em  Co-  'j 

I 

- Two  Burroughs  B-6700s  (referred  to  as  "A"  and  "B") 

--  Each  has  three  central  processors  and  two  Input/Output 

processors,  5 . !Hz  clock,  multiprocessing  and  mu ltiprogr aiming 

--  Memory,  overl ayabl e/virtual , 7~0  ns  to  1.6  us  access 

— "A"  has  703K  words  (4.2  million  characters) 

"B"  has  524K  words  (3.1  million  characters) 

--  Fixed-head  disk  storage,  auxiliary,  23  ms  access 

— "A"  has  220  million  bytes 

— "B"  has  120  million  bytes 

--  Dual  disk  pack  drives,  50  ms  access 

"A”  has  34  drives  (7.2  billion  bytes) 

— "B"  has  33  drives  (4.0  billion  bytes) 

j — 21  drives  are  shared  by  both/ei thcr  (3.7  billion  bytes) 

--  Magnetic  tape  drives,  9 channel,  1600  bpi,  520K  byte  transfer 

— "A"  has  16  drives 

— "B"  has  12  drives 

— Also  three  9 channel  800  bpi  and  two  7 channel  556  bpi  drives 
--  Line  printers 

— "A"  lias  one  1100  1pm  IBM  train  and  one  750  1pm  Burroughs  train 

— "B"  has  two  1100  1pm  Burroughs  trains 

--  Card  readers 

— "A"  has  two  800  cpm 

"B"  has  one  300  cpm,  and  one  300  cpm  auxiliary 

--  Card  punches 

"A"  and  "B"  have  one  300  cpm  each 
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--  Operator  consoles 

— "A"  and  '*&*'  have  on < con  >le  < h with  dual  di:  1 : 

"A"  and  "B"  each  have  dual  displays  remote J to  syst c 

— Data  communicat  ions 

— "A"  lias  four  data  communications  processors,  each  with 
8k  words  local  memory 

Two  have  si:;  adapter  clusters  each 

Two  have  three  adapter  clusters  each 

— "B"  has  two  data  communications  processors,  each  with 
8k  words  local  memory  and  three  adapt  r clusters 

--  Remote  devices 

— 311  CRT  terminals  (1200-2400  baud)  with  companion 
printers  (plus  130  for  MAJCOM,  46  for  OCPO) 

— 00  keyboard  and  dial-up  type  terminals 
— Five  RJE  mini-computers 

— Five  remote  communications  processors/printers 
(plus  14  for  MAJCOM) 

One  Honeywell  H6040 

--  One  central  processor  and  one  Input/Output  processor, 
mult iprogramming 
--  131,072  words  of  memory 
--  Eight  disk  pack  drives,  548  million  bytes 
--  Six  magnetic  tape  drives,  9 channel  SOObpi 
--  One  1150  1pm  train  printei 
--  One  900  cpm  card  reader 
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--  One  master  operator  console 

--  One  data  net  355  front-end  communications  processor  with  16K 
--  Ten  CRT  terminals  (plus  30  for  Microform  enchancement) 

One  Burroughs  B1700  small  computer  (van-mounted  for  PERSCO) 

One  each  Burroughs  B776  and  B376  for  MAJCOM  prototype  space 
development  and  testing 

One  Burroughs  B771  for  program  development  and  operations  testin 
One  Hewlett-Packard  HP2116B  for  marked  card  scoring  and  tape 
conversion 

One  Varian  (Univac)  6201  for  Microform  fiche  mounter  control 
One  12,000  1 pin  Honeywell  Page  Printing  System 
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C rile  ami  Program  Series  Codes  (Ref  9) 


Note:  Questions  on  the  use  of  these  codes  should  be  addressed 
to  AFMPC/DPMDDS3 . 


Program  Serie's  Code 


Cod  e 

Program  Series 

AA 

Airman  Active  MPF 

AB 

Airman  Active  Asgmt  Action  File 

AC 

PROMTS 

Al) 

MA.TCOM  Deployment  File,  Airman 

AI- 

ARRAS  (Reserve  I,  Guard) 

AG 

Airman  Guard  MPF 

AI 

AIMS 

A.J-AM 

Program  Conversion,  Current  System 

AP 

Career  Job  Reservation  File 

AQ 

Reenlistment  Quota  Bank  File 

AR 

Airman  Reserve  MPF 

AT 

atlas/shop  com; 

AU 

AFSC  Conversion  (Airman) 

AW 

WAPS 

AX 

ARMS  Accounting 

AZ 

Airman  Retired  Master  File  (Reserves) 

P>A 

Officer  Active  MPF 

BB 

Officer  Active  Asgmt  Action  File 

BC 

Officer  Accession  Analyzer 

Bi) 

MAJCOM  Deployment  File,  Officer 

BP. 

JOB  FILE 

BF 

Board  Support 

BG 

Officer  Guard  MPF 

Bll 

AFIT  Quota  Bank  File 

BT 

Officer  Assignment  Indicator 

BJ 

OSSM  Officer  siml  sys  model 

BK 

Officer  Follow-on  Asgmt  File 

BM 

OER  Format  Conversion  File 

BN 

Assignment  Stability  File 

BO 

Officer  Authorization  Entitlement 

BP 

Officer  Manpower  Data  Compare 

BQ 

UFT  Schedule  Model  Pile 

BR 

Officer  Reserve  MPF 

BS 

Officer  Separated  History  File 

BT 

Retraining  Analyzer 

BU 

AFSC  Conversion  (Officer) 

BV 

AFR/ANG  Board  Support 

BW-BY 

Program  Convulsion,  Current  System 

BZ 

Officer  Retired  Master  File  (Reserves) 
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Code 

Program  Series 

CA 

Ci vi 1 i an  MPF 

Cll 

Civilian  Historical 

DA 

Death  History  File 

DC 

Casualty  Hostile  Action  File 

DD 

Decorations  Awards  Slat  F'ile 

DE 

ARMS 

DM 

Contingency  MANFOR  File  (HAF  level) 

DQ 

Contingency  Requ i rcmcnts  (HAF  Level 
(Officer  and  Airman) 

DR 

Contingency  Retrieval  File  (HAF  Level 
(Officer  a n d A i rm an ) 

DS 

Contingency  State  File  ii  Duty  Status  (HAF) 

DT 

TOY  Deployment  Auth/Asgd  Stat  File 

DU 

Contingency  UTC  File  (11A1) 

i;a 

Personnel  Dist  by  Country  or  other 

Specified  Area 

EB 

Personnel  Dist  by  Operating  Location  in 
CONUS 

EC 

P.J 

Officer  ?i  Airman  Combined  Reports, 

Program  Conversion,  Current  System 

E20 1 File  Extract 

FA-FQ 

Reserved  f or  Tech  Tra i n i ng 

FR 

Mobilization  Filler  (Reserves) 

FS-FZ 

Reserved  for  Tech  Training, 

GA 

Guard  Airmen  Reports 

GC 

Guard  Combined  Reports  (Officer  f(  Airmen) 

GI 

COM  Processing 

GN 

GODS  (Gen  Off  Date  System) 

GO 

Guard  Officer  Reports 

GR 

PCARS  (ANC  1,  RESERVES) 

HA 

Tors  Human  Rel  Perm  Disq  (Officer  5 Airmen) 

ID 

Drug  Abuse 

IM 

Integrated  Manning  Pile 

I.A-I.D 

Reserved  for  1IAF  Retrieval 

LF 

Micro -Form  File 

LG-LII 

Reserved  for  HAF  Retrieval 

LI 

Micro-Form  On-Line 

1,1-  LL 

Reserved  for  11AF  Retrieval 

LM 

Micro- Forn  Mon i tor 

LN-I.Q 

Reserved  for  I1AF  Retrieval 

I.R 

Micro -Form  Appl i cat  ion 

I-S 

Micro-Form  System  Software 

LT-LZ 

Reserved  for  HAF  Retrieval 
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Cod  o 

Program  Series 

MA 

Course  Sui'- nary  File 

MB 

SAN  Master  File 

MC 

Training  Requirements  File 

Ml) 

TPR  AI-'SC  File 

mi: 

Daily  Load  File 

Ml- 

Prog/Actual  Monthly  Summary  File 

MG 

Actual  Summary  File 

Mil 

Training  Course  Data  File 

MJ 

Training  Manager  Profile  F'ile 

MK 

Factors  File 

ML 

Projected  Student  File 

MM 

Requirements  Trans  Hold  File 

MT 

Micro-Form  ADDS  Interface 

MY 

Flying  Man  Years  File 

NA 

Available/Non-Avai lahle  File 

NG 

ANG  TPM IS 

OA 

Off  i c.er  Change  F i 1 e 

OB 

Flying  Hour  Analysis  File 

OC 

Officer  St at  File 

on-oz 

Reserved  for  PPMRO  Uniques 

PA-PG 

Reserved  for  Tech  Training 

I'll 

Privacy  Act  Historical 

PL 

Reserved  for  Tech  Training 

PN-PO 

Reserved  for  Tech  Training 

PP 

PAS  Master  File  (HAF  hovel  J 

PQ 

Reserved  for  Tech  Training 

PR 

Privacy  Act  Tracking  System  (PATS) 

PS-PZ 

Reserved  for  Tech  Training 

QA 

Reserved  for  Tech  Training 

RA 

Retired  Airman  Master  File 

RB 

Retired  Officer  Master  File 

RC 

Reserve  Combined  Reports  (Officer  f,  Airroc 

RD 

RPDS  fid  its 

Rl: 

Reserve  Enlisted  Reports 

RF 

Reserve  Table-Tape 

RG 

Reserve  Grid-Zip 

Rll 

TDRL  File 

RM 

Reserve  Manpower  Rcprots  System 

RO 

Reserve  Officer  Reports 

RQ 

Air  Force  Active  Off  Ft  Unlisted  Reports 

RR 

Air  Force  Guard  Rose  ve/Reports 

RS 

Rctircmcnt/Sopar.’t  i on  St  it  File  (Active) 

RT 

Retirement/S. -!»arat  ion  St  » t File  (USA!  111 

Rl) 

Retirement /Sc pe rat  ion  (ANG) 

RV 

Project  CAPTURE  Update 
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Code 

Program  Scries 

SA 

APP  900-2  Awds  f(  Decs  Pamphlet  by  Units 

SB 

Program  Conversion  HA!'  bcvle  MPR's 

sn 

DMS  Utility 

SM 

Standard  Microfiche  Products  (MAP  bevel) 

so 

Station  Organization  Master 

SP 

Standard  Products  CHAP  bevel) 

SIJ 

Software!  Utilities  (IIAP  bevel) 

sw 

Software  System  (IIAP  bevel) 

sx 

HAM IS  Transactions  (Prom  Base  bevel) 

TA 

'IRA  PM  1 S 

TB-'l'D 

School  Quota  Control  System 

TP-TZ 

Reserved  for  Tech  Training 

UT 

Reserved  for  Subsystem  Code  16 

WA-WZ 

Reserved  for  Washington  Area  Support 
(DPMDW  f,  PPMHD) 
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VITA 


Lester  Emil  Nagel  was  born  on  23  September  1935  near  Defiance,  Ohio. 

He  graduated  from  North  Richland-Adams  High  School  near  Jewell,  Ohio  in 
1953  and  attended  The  Defiance  College,  Defiance,  Ohio  from  which  he 
received  a Bachelor  of  Science  degree  in  1957.  Upon  graduation,  he  was 
employed  by  the  Board  of  Education  at  Chatfield,  Ohio  as  a high  school 
mithematics  and  science  teacher,  lie  enlisted  in  the  Air  force  and  enrolled 
in  the  Officer  Training  School  (OTS)  program  on  22  December  1959  and  was 
commissioned  on  22  March  1960.  Ik-  compl et ed  navigation  training  and  received 
his  wings  on  13  December  1960.  In  1901,  he  completed  navigation-bombardment 
training  and  was  assigned  to  a B-52  crew  in  the  Strategic  Air  Command  (SAC). 

He  spent  7 years  in  SAC  performing  crew  duties  as  navigator,  radar-navigator, 
flight  instructor,  and  flight  examiner  in  the  19th  and  17th  Bombardment 
Wings  (SAC),  lie  was  assigned  to  the  operations  staff  of  the  17th  Bombard- 
ment. Wing  (SAC)  as  a target  study  officer  in  1968.  In  1972,  he  was  assigned 
to  the  43rd  Strategic  Wing  (SAC)  on  the  island  of  Guam,  where  he.  was  an 
aircrew  target  study  officer  for  the  B-52  Arc  Light  missions  over  Southeast 
Asia.  He  was  assigned  to  t he  Strategic  Air  Command  Headquarters  staff  and 
the  Joint  Strategic  Target  Planning  Staff  at  Offutt  AFB,  Nebraska  in  1974 
until  he  entered  the  School  of  Engineering,  Air  force  Institute  of  Technology, 
in  August  1976, 

Permanent  Address:  Route  2,  Brandt  Road 

Defiance,  Ohio  43512 
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JO.  continued. 


and  may  provide  a solution  to  these  problems.  Consequently,  a discuss. ‘on  of  tin: 
back-end  concept,  its  advantages,  and  dir..-  lvontay.e:  is  presented,  in  addition. 


the  gener  1 requirement:  <.  : th(  system  are  a is cussed  and  are  divided  into  two 
categories;  f"  i £ incti  nal  requi  - ni  5,  and  TS-jl  system  requirements 

The  discussions  of  the  current  system,  the  personnel  management  or^anTtrst-lcc 
the  back-end  concept,  and  the  general  requirements  provide  a foundation  for 
uture  stud  i 1 s taat  will  be  requir-  to  (J)  solve  the  system  problems.,  and  (2) 
model  ..  back-end  data  ba  < proces  system  configuration  foi  the  AFMPC.  in 
addition  to  the  baekyound  and  foundation  lor  future  studies,  a focus  and 
direction  fo  : - . tudies  is  also  resented.  Fhe  focus  and  lirection  for 
'uture  : tu-.j  e>  is  pi  o'.  1 Jed  throu  U (1 ' an  analysis  of  the  current  system,  2) 

*•  plan-o f-  :.i  ta„  k id  -n.  c .-  u'-.-.I  .0  solve  the  data  mans,? ..nent  proi-1  us  o*i  the 
‘-.die;,  a id  - a :.-rirL  look  at  the  icat ion  of  a back  nd  data  base 
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